Note: The Ericsson internal website containing all TelORB documentation
      is no longer maintained (from Nov 1, 2002), and all information regarding
      e.g. TelORB R14 (JAP 3.0) and TelORB R14-Linux (TSP 4.0) will be removed.
      Instead, all documentation for TSP 4 and earlier/later releases will be
      available as .pdf files in GASK, and as ALEX books located in CPI Store
      at http://cpistore.ericsson.se.
      CPI Store will contain the two latest releases of ALEX books.

      Some instructions for how to navigate in CPI Store can be found below.

--  --  --  --  --  --  --  --  --

Go to and navigate in CPI Store (ALEX)

- Go to CPI Store.
- Click "Enter" (Active Library EXplorer (ALEX) will load).
- Search document: TSP      Click "Search".  (Top of page)
- Click e.g. "Ericsson Telecom Server Platform (TSP) 4.0" (Choose the latest
  version).

-- -- -- -- -- --

Find e.g. TelORB Configuration Parameters for TSP 4.0:

- Go to CPI Store.
- Click "Enter" (Active Library EXplorer (ALEX) will load).
- Search library: TADE      Click "Search".
- Click "TSP Application Development Environment (TADE) 4.0" (Choose the latest).
- Search library: config    Click "Search".
- Click "TELORB CONFIGURATION PARAMETERS".

Hints
To be able to see all documents in ALEX, make sure that you have all boxes
ticked in "User preferences" which is opened by clicking the corresponding icon
"Change user preferences" at the top of the ALEX page.

GASK
http://gask2web.ericsson.se
Use your RACF password to enter GASK.

TagTool (e-mail from Tapio Lanki 2004-06-04)
To avoid compatibility problems (templates and different TagTool versions),
start TagTool as follows:

From the rootmenu, select Document Handling->APSsystem 4.1 Rev O (System
Default)

Then, start TagTool by double-clicking on "TaG R8".

--  --  --  --  --  --  --  --  --

ALEX books lazy dog

The people working with the "Alex books" have produced this "lazy dog"
for finding things in the documentation. Please read and refresh your
skills.

1. Go to http://cpistore.ericsson.se.

2. Click Enter at the bottom.

3. Write tade in the Search Library field at the top, to the left.

4. Click on the title of the ALEX library you want to open.

5. Expand folders and subfolders to see the included documents.

   Please note: If a user wants an overview, that is, a list of all the
   included document, the best thing to do 
   is to fetch the Structured Document Index (SDI) from GASK! The SDI is
   the specifiction of the library.
   It specifies the folder structure and all the included documents. 
   Below I have attached the SDI of the latest TADE 4 ALEX library.

6. Within the ALEX library, you can easily search for a specific
   document or for specific information:
   (You do not have to open folder by folder, unless you want to.):

   Just write for example applog or a document number, or the beginning
   of a document number in 
   the Search document field.

   You will get a list of matching documents. The hits will refer to the
   document title or the document body.

7. Within the document you can then search for specific items:
   a) In a PDF document: Use the Search function on the tool bar. It is
      indicated by the binoculars icon.
      (Not very good by the way. The search function regarding sgml/xml
      documents works much better, but as you know most of the sgml/xml
      documents will appear as from TADE 5.)
   b) In an sgml/xml document: Write for example applog in the Search
      document field and  
      information about "AppLog" will be red-marked inside each and every
      matching document.

(Source: E-mail from Chris Smith, 2004-06-28)

--  --  --  --  --  --  --  --  --

Old ways of accessing documentation

Below you will find links to the official TelORB Operations and Maintenance
Documentation for different TelORB releases.

TelORB R13

TelORB AD12

TelORB AD9.05

TelORB R14 - Configuration Parameters and Tools


Below you will find old links to the unofficial TelORB Operations and
Maintenance Documentation for TSP 4.0 (R14-Linux) and R14 TelORB releases.

TelORB R14 on GEM Hardware for TSP 4.0 (OS and Clusterware)

TelORB R14 on GEM Hardware

TelORB R14 on Carmencita Hardware


--  --  --  --  --  --  --  --  --

Document revision rules

Forbidden revision characters:
I, O, P, Q, R, W

Revision rules:
- Start with R1A01
- First EC is R1A02
- First CM is R1B01
- First "big" functional lift is R2A01

General
 (Updated: 2003-10-30)

CDM is a complete Product Data Management (PDM) system, which can support the
entire life cycle of any Ericsson product in the extended Ericsson world.
It has full support to handle all aspects of Data Management for a product,
including maintaining product structures, handling of all kind of related
documents and data, version control, support for a collaborative approach for
teamwork, etc.

CDM stands for Collaborative Data Management.
Both Corporate and DCND have decided to roll out CDM as the document management
system for the R&D organizations (at DCND the decision was made on PMTC on
September 9th 2003).
CDM is introduced for handling of both reference notation documents (office
documentation) and registration notation (projects and products).

Document revision example:
  PA1 --> PA2 --> A --> PB1 --> PB2 --> PB3 --> B --> PC1 --> C

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Log in to CDM
 (Updated: 2003-10-30)

- Open the CDM Center homepage.
- Click "LOGIN to CDM".
- Use your Corporate ID and your LAN password to log in.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Useful links
 (Updated: 2003-10-30)

CDM Center

CDM User Guides


== == == == == == == == == == == == == == == == == == == == == == == == == ==

TSP 5: Product numbers, decimal classes and CDM
 (Updated: 2003-12-12)

(Source: E-mail from Tapio Lanki, 2003-12-12, slightly modified by Michel)

TSP5 product numbers
--------------------
Clusterware/OS:                  APR 901 578/1
Clusterware/OS TADE Components:  APR 901 595/1


Decimal classes to be used for APR 901 578/1 (TSP)
--------------------------------------------------
n/1551-APR 901 578/1 Description
n/1551-APR 901 578/1 Notification
n/1543-APR 901 578/1 OPI
n/1543-APR 901 578/1 Alarm
n/1553-APR 901 578/1 User Guide (N.B. not "User's Guide")


Decimal classes to be used for APR 901 595/1 (TADE)
---------------------------------------------------
n/155 17-APR 901 595/1  Function Specification
n/198 17-APR 901 595/1  Programmer's Guide
n/1553-APR 901 595/1    Reference Manual
n/1551-APR 901 595/1    Description
n/102 60-APR 901 595/1  Design Rules
n/1553-APR 901 595/1    User Guide


About templates
===============
A "User Guide" (dec. class 1553) exists as a template. In case you
want to write a (say)
"Reference Manual", change the title for the document from "User
Guide" to "Reference Manual".

Templates etc. for e.g. CPI and DPI can be found in

  http://ccnd.ericsson.se/controlsystems/projectinfo/tsp5/documentation.htm

The template for the User Guide can be found in the "CPI Guidelines &
Templates" list.
Use that for TADE also.


About titles
============
The user guide for JDB (for example) has the decimal class 1553, the
product number APR901595/1
(because it is a TADE document). The title itself MUST contain the
words "User Guide", in this
example "JDB User Guide"


CDM
====
How to create your own personal query, without having to navigate via
the product?
So far it is not a problem, but when the number of documents increases...

1. In Solaris environment, start "Document Handling->CDM" (takes a while).
2. Select "Query->Documents->Registration Notation"

   A form appears. Fill in:

3. "Prepared". Insert your user id in CAPITAL LETTERS (stupid, ehh?)
   (NOTE! If you have created a document for a collegue, the value of
   this field may be wrong, but in most cases this works)
4."Language". Select Uen (not necessary, but why not do it anyway?)
5. "User/Vault". Click on the box and select "TSP Project Vault"
6. "Access Area". Click on the box and select "TSP".
7. Press "Save..."
8. In the new window, give your query a name, e.g."my TSP5 docs"
   This query is now available in your web client in Saved Queries.

Based on this query, you can easily create additional queries, for
example one query for only TSP documents (filter "Document Number"
with "*-APR901578/1"....without the quotation marks, of course),
and another for TADE documents.

(Source: E-mail from Tapio Lanki, 2003-12-12, slightly modified by Michel)

Contents
 (Updated: 2003-09-09)

General
Log in to ClearQuest
Submit a TR

== == == == == == == == == == == == == == == == == == == == == == == == == ==

General
 (Updated: 2003-06-05)

Ericsson Core ClearQuest (CCQ/TR) should be used to report problems found in the
OS/ClusterWare part of the following TSP products (including reporting
documentation faults and also suggestions for improvements):
- JAP 3.0   (TelORB R14)
- TSP 4.0   (TelORB R14-Linux)
- TADE 3.0  (TelORB R14)
- TADE 4.0  (TelORB R14-Linux)
- TSP 5.0   (TelORB R15)
- TADE 5.0  (TelORB R15)

Market reference series to be used in TSP 5.0:
    OS&CW
      TSP5-OSCW-FT-nnn
      TSP5-OSCW-SSV-nnn
    Node management
      TSP5-NM-FT-nnn
      TSP5-NM-SSV-nnn
    SS7
      TSP5-SS7-FT-nnn
      TSP5-SS7-SSV-nnn
    I&V
      TSP5-INT-nnnn  (defined in MHS)
      TSP5-SV-nnnn   (defined in MHS)

ClearQuest is now (from 2003-06-05) the tool for work in TSP OS/ClusterWare and
your authority in EAB-TSP-CS (previously EAB-TSP) is "Browser".

To use ClearQuest you need a userid and a personal password.

You can find more ClearQuest information, like guides and FAQs by following the
links below:
- Guidelines
- FAQ
- Pilot

The old trouble report handling system, TRtool and TRweb, can no longer be used
for answering and registering TRs in EAB-TSP-CS (previously EAB-TSP). (From May
28, 2003.)

The even older trouble report handling system, ClearDDTS, should not be used for
the above stated TSP products. (From Nov 1, 2002.)
However, ClearDDTS should still be used for earlier TSP releases.

If you have problems using ClearQuest or want to report errors on it, use the
following link: PSP Support & Maintenance.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Log in to ClearQuest
 (Updated: 2003-09-04)

- Enter ClearQuest by following the link below:
    http://clearquest.ericsson.se/ccq-tr/ and then click the "CCQ/TR login" button.

  or login directly by using the following URL:
    http://ccq.ericsson.se/ccqweb/logon.

- When you have entered the login menu in ClearQuest (Rational ClearQuest),
  enter and select the following:
    User Name: <Your_user_name>
    Password: <Your_personal_password>
    Schema Repository: TSP
    Database:          TSPTR
                       TSPTR - TSP TR Database

- Click "Logon".

- To change your personal password for accessing ClearQuest, perform the
  following steps once you are logged in:
  - Click "Operations" (top left corner).
  - Select "Change User Profile".
  - Fill in the new "Password" and "Confirm New Password".
  - Click "Commit".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Submit a TR
 (Updated: 2003-09-09)

- Log in to ClearQuest, as described above.

- Select "ERI_TR" next to "Submit" in the top left corner.
- Click "Submit".

- Click "Add" next to the input field for "prod_number" and "prod_name".

- Click "Select Query".

- For TSP 5.0, select "Public Queries/TSP ClusterWare_OS/TSP 5.0_product" and
    click "Select".
  For TSP 4.0, select "Public Queries/TSP ClusterWare_OS/TSP 4.0 Product" and
    click "Select".
  For JAP 3.0, select "Public Queries/TSP ClusterWare_OS/JAP 3.0 Product" and
    click "Select".
  Or select another valid option from the list and click "Select".

- Tick the product name and number which corresponds to the product to issue
  the TR for, e.g.
  for TSP 5.0 runtime: "TSP 5.0 ClusterWare/OS | APR901578/1"
  or for TSP 4.0 runtime: "Clusterware/OS TSP4.0 | APR901268/3".
- Click "Add".

- Fill in or make selections for all fields with Red headings.
  Some useful information when doing this:
  - ID / R-state can be specified by making a selection in the empty input
    field below (or next to) the "prod_number" and "prod_name" input field.
    For TSP 5.0 select "R1A".
    For TSP 4.0 select "R1".)

  - ID / Synchronized with MH should be set to No.
       (The synchronization cannot, for some stupid reason, be done before the
        TR has been submitted. Instructions for how to synchronize the TR can
        be found further down.)

- Also select the following (not necessary, but nice to have):
    ID / CCB: TSP ClusterWare/OS

- Click "OK" in the upper left corner to submit the TR.

Now that the TR has been submitted, you have to synchronize it with MHS as
follows:

- Click "Continue".

- Click "TRs Submitted by me" in the Workspace menu on the left hand side.

- Select "Submitted" for the "Enter State?" question.
- Click "Run Query".

- Select the just submitted TR below "#", to be able to synchronize it.

- Select "Modify" in the "Actions" input field at the top of the page.

- Enter and select the following:
  - ID / Synchronized with MH: Yes

  - Notes / Notes: Synchronized with MH

  - MH / Site Status:   OPER              (No value required for TSP 4.0)
  - MH / Customer:      TSPSST (For TSP 5.0)   UNDEF (For TSP 4.0)
  - MH / ISP Customer:  N Not ISP fault                 (Value required?)

  - AXE / Site:         AS                (No value required for TSP 4.0)
  - AXE / Country Code: SE                (No value required for TSP 4.0)
  - AXE / Market Reference: TSP5-CWOS-SST (For TSP 5.0)
                                          (No value required for TSP 4.0)
  - AXE / AS:           ANA90103/2        (For TSP 5.0)
                                          (No value required for TSP 4.0)
  - AXE / AS R-state:   R4A               (For TSP 5.0)
                                          (No value required for TSP 4.0)

- Click "OK" in the upper left corner to commit the synchronization.

- Click "Continue" and verify the data.

- If desired, Click "LogOff" in the upper right corner to exit the ClearQuest
  session.

Select valid TSP release
 (Updated: 2005-03-01)

TSP 5.1 and later   (next link also includes some valueable information
                     for TSP 5.1 and later)
TSP 5.0 and earlier (some info also valid for TSP 5.1 and later)
Old trouble reporting tools


== == == == == == == == == == == == == == == == == == == == == == == == == ==

Contents - TR info for TSP 5
 (Updated: 2005-03-01)

Write a trouble report on a product
Write a trouble report on a document
Check your TR worklist
Additional trouble report info

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Write a trouble report on a product
 (Updated: 2005-05-09)

- Open MHWeb.

- In the left hand "Tools" column, click "TR".

- In the left hand "Tools" column, click "Create TR (Product)".

- Log in using your RACF password.

- Fill in the following fields:

    *** For a complete list of Work Packages mapped to LSVs/MCPs, see
    Work Packages <-> LSV/MCP Mapping ***

  -----------
  Description
  -----------
    Heading:          MCPn: <Heading> (or e.g. MCPn, WPn: <Heading>)
    Priority:         <Select A for High, B for Medium or C for Low>
    Customer:         TSP CWOS
    Market Ref:       Select on e of the following alternatives:
                      For CW/OS: TSP5-CWOS-FT -or- TSP5-CWOS-DSV
                      For NM:    TSP5-NM-FT   -or- TSP5-NM-DSV
                      For SS7:   TSP5-SS7-FT  -or- TSP5-SS7-DSV -or- TSP5-SS7-SSV
                      For I&V:   TSP5-INT     -or- TSP5-SV
                      For Diameter: TSP5-DIM-FT -or- TSP5-DIM-SV
                      (An autogenerated number will automatically be added at
                      the end of the entered market reference value)
    Cust ISP Code:    Not ISP fault (Not affecting in service performance)
    Country Code:     SE
    Site:             AS
    Site Status:      TEST   (Use BT, DT, ET, FT, FTT, SPV, ST instead?)

    Designation:      Clusterware/OS
    Product Number:   APR 901 578/1  R-State: R2H02   (For TSP subsystem, LSV15)
                          -or-
                      APR 901 595/1  R-State: R50AA01 (For TADE subsystem, LSV9)
                                              (See below for further subsystems)
                      How to get the correct R-State for a product:
                        source /ipims_dicos/BS2/tbWPn/Setup.csh  (Adjust tbWPn
                                                          to valid work package)
                        epsi tree -m APR901578/1

                      (Try to avoid TRs on ANA level, i.e. state the Product
                       Number as low in the structure as possible, e.g. IDP/APR;
                       CRA 119 663/2.)
                      Click on the appropriate link to get the product
                      structure for either TSP 5 or TADE 5.

    AS/SS System:     ANA 901 04/1    R-State: R2A    (For TSP 5.1 subsystem)
                          -or-
    AS/SS System:     ANA 901 04/1    R-State: R3A    (For TSP 5.2 subsystem)

                          -or-

    AS/SS System:     ANA 901 31/1    R-State: R2A    (For TADE 5.1 subsystem)
                          -or-
    AS/SS System:     ANA 901 31/1    R-State: R3A    (For TADE 5.2 subsystem)


    1st Tech Contact: UABxxx
    Information:      -

    Additional Info:  TSP5.n MCPn WPn    (Adjust TSP5.n, MCPn and WPn to valid
                                          TSP release, LSV and work package
                                          identity)

    Remember to write the "TACOS TCid reference" in the "Observation" area, as
    instructed below!

  -----------
  Observation
  -----------
    EFFECT:      <Short explanation of the problem>

    DESCRIPTION: <Detailed description of the problem>
                 <If you need to add enclosures, you will be instructed to
                  do so below (ENCL, ENCL1 etc.)>

                 TACOS TCid reference: xx.yyy  (Fill in the Test Case identity,
                                                if this TR is the result from
                                                executing a TACOS test case,
                                                e.g. TCid 02.003)

                 If the main problem is a capsule abortion, include the slogan
                 of the capsule abortion.

    MEASURES:

SYSTEM CONFIGURATION:

General
-------
Test date:                  March 3, 2005
Tester:                     Michel Sundin

Software data
-------------
Release:                    TSP5.1, LSV9, WP14
SW source: source /ipims_dicos/BS2/tbWP014/tsp_deliverables/Setup.csh
TLMs:                       -
Linux version on IOs:       2.6.5-tsp1 (uname -r)     (Previously 2.4.21-R2A42)
Linux version on TPs:       2.6.5-tsp1 (uname -r)     (Previously 2.4.21-R2A42)
Installation DVD version:   APRCWOSTEST_1 Rev R50S01T,""...WP14...""
TelORB Manager version:     R50S03

Node data
---------
Test node:                  to15
Node type:                  NSP 4.1
SW configuration:           Maxi, DicosMax (only 31 processors used)
Network redundancy:         No
Partitioned NetRed:         No
Total amount of processors: 31
No. of Dicos TP processors: 14
No. of Linux TP processors: 15
No. of Linux IO processors: 2
No. of Linux FS processors: 0
IOs in the TSP cluster:     No
VIP address:                134.138.71.15

TSP Ref App traffic data
------------------------
Pool configuration:         De2SubPool on all Dicos processors.
                            De2SubLinuxPool on all Dicos processors.

POPULATE (Database):        Size of Objects: 666 bytes
                            Ranging from: 0    Ranging to: 2000000


Dicos traffic:	
      Internal traffic:
			C++:  CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 26000            (calls/sec)
                              Ranging from: 0    Ranging to: 2000000

			Java: CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 20000            (calls/sec)
                              Ranging from: 0    Ranging to: 2000000

      External VIP traffic:
			C++:  CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 500              (calls/sec)
                              Ranging from: 0    Ranging to: 2000000

			Java: CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 500              (calls/sec)
                              Ranging from: 0    Ranging to: 2000000

Linux traffic:
      Internal traffic:
			C++:  -

			Java: -

      External VIP traffic:
			C++:  -
			Java: -

File Server Traffic:    None

External traffic generators:
			134.138.186.235 (Michel's Linuc PC):
/home/dicosarc10/archive/LSV1/cwos-LSVtsp51base-test/system/TelORB/IDP_VIP101_R1A02-VIPtrafficgenerator/included/LM_VIP101-VIPtrafficgenerator/bin/VIPtrafficgenerator.LM_VIP101.R2A02.i486-Redhat-6.0 172.30.14.14 5987 5988

Processor load
--------------
Dicos, Cluster Control:     0%
Dicos, Normal TPs:        ~54%
Linux, IOs:              ~3-5%
Linux, Normal TPs:       ~3-6%

Processor memory usage (Memory usage, DBN memory usage)
-------------------------------------------------------
Dicos, Cluster Control:     5%, 0%
Dicos, Normal TPs:      12-13%, 8%
Linux, IOs:               4-7%, 0%
Linux, Normal TPs:        5-6%, 0%

- Click "Save as new TR".

- Add enclosures, if any.

- At "Actions", select "Register".
- Click "Execute".

- If no enclosures have been added to the TR, a popup window with the text
  "No enclosures have been added to the TR." will appear.
  Click OK, if you do not want to add enclosures, or click cancel if you want
  to add enclosures (add enclosure(s) and then proceed below).

- In the "Register" window, select the proper MHO (e.g. EAB-TSP-CS) and then
  click "Execute".

- If you know who should handle this TR, at "Actions", select "Assign to
  Handler".
- Click "Execute".

- In the "Assign To Handler" window, select the valid user to assign the TR to
  and then click "Execute" (at the bottom of the window).

- Verify that the "Status" field is set to "Analysis Started" and that the
  correct owner is stated in the "Owner" field.

Hint
----
If you get the following information message when trying to save a new TR,
register a TR, assign a TR, etc. I've detected a way to get out of this
unpleasant state:

  Information Message
  Thrown by N/A.N/A().Can not retrieve connection.

Change the "Cust ISP Code" to another setting and then click "Save as new TR".
Then change the "Cust ISP Code" back to "Not ISP fault (Not affecting in service
performance)" and click "Save as new TR".

-- -- -- -- -- -- -- --

More R-state info for TSP5.1, LSV9 can be found in:
TSP and TADE, respectively.

The Official Product Structure can be found in:
TSP5 and TADE5, respectively.

(Source: E-mail from Stefan Björnelund, 2005-02-28)

-- -- -- -- -- -- -- --

Official MHWEB documents can be found at the following locations:

    - How to issue a TR within TSP 5

https://psp.uab.ericsson.se/tsp/deliveries/TSP5_PI/TSP5_product_introduction/TSP5_PI_Documentation/TRB/Issue_TR/How%20to%20Issue%20a%20TR%20within%20TSP5.ppt

https://psp.uab.ericsson.se/tsp/deliveries/TSP5_PI/TSP5_product_introduction/TSP5_PI_Documentation/TRB/Issue_TR/How to Issue a TR within TSP5.ppt

-- -- -- -- -- -- -- --

Following is a list of different Customer / MarketRef Series that SHALL 
be used when writing TRs on different subsystem within TSP5.1

TSP SubSystem			Customer	MarketRefSerie
ClusterWare/OS	APR901578/1	TSP CWOS	TSP5-CWOS-DSV-nnn
						TSP5-CWOS-FT-nnn
TADE SubSystem
ClusterWare/OS	APR901595/1	TSP CWOS	TSP5-CWOS-DSV-nnn
						TSP5-CWOS-FT-nnn
Use "CountryCode" SE / "Site" AS

In field "Additional Info" fill in the WP the fault is found in ex
"TSP 5.1 LSV5 WP079"

Follow is a list of productnumber for the other subsystem in TSP5.1
TSP NodeManagement	APR901591/1
TADE "			APR901590/1

TSP Signalling		APR901382/2
TADE "			APR901654/1

TSP Diameterbase	APR901760/1	
TADE "			APR901759/1

TSP Hardeware		APR901235/1
TADE Performance
SimulationTool		APR901340/2

(Source: E-mail from Helen Hargin, 2005-01-17)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Write a trouble report on a document
 (Updated: 2005-03-09)

- Open MHWeb.

- In the left hand "Tools" column, click "TR".

- In the left hand "Tools" column, click "Create TR (Document)".

- Log in using your RACF password.

- Fill in the following fields:

    *** For a complete list of Work Packages mapped to LSVs/MCPs, see
    Work Packages <-> LSV/MCP Mapping ***

  -----------
  Description
  -----------
    Heading:          MCPn: <Heading> (or e.g. MCPn, WPn: <Heading>)
    Priority:         <Select A for High, B for Medium or C for Low>
    Customer:         TSP CWOS
    Market Ref:       Select on e of the following alternatives:
                      For CW/OS: TSP5-CWOS-FT -or- TSP5-CWOS-DSV
                      For NM:    TSP5-NM-FT   -or- TSP5-NM-DSV
                      For SS7:   TSP5-SS7-FT  -or- TSP5-SS7-DSV -or- TSP5-SS7-SSV
                      For I&V:   TSP5-INT     -or- TSP5-SV
                      For Diameter: TSP5-DIM-FT -or- TSP5-DIM-SV
                      (An autogenerated number will automatically be added at
                      the end of the entered market reference value)
    Country Code:     SE
    Site:             AS
    Site Status:      TEST   (Use BT, DT, ET, FT, FTT, SPV, ST instead?)

    Document Number:  <Document number>               Revision: <Revision>
                      E.g. 1/1531-ANA 901 04/1-19               E.g. A

    AS/SS System:     ANA 901 04/1    R-State: R2A    (For TSP 5.1 subsystem)
                          -or-
    AS/SS System:     ANA 901 04/1    R-State: R3A    (For TSP 5.2 subsystem)

                          -or-

    AS/SS System:     ANA 901 31/1    R-State: R2A    (For TADE 5.1 subsystem)
                          -or-
    AS/SS System:     ANA 901 31/1    R-State: R3A    (For TADE 5.2 subsystem)


    Additional Info:  TSP5.n MCPn WPn    (Adjust TSP5.n, MCPn and WPn to valid
                                          TSP release, LSV and work package
                                          identity)

  -----------
  Observation
  -----------
    EFFECT:      <Short explanation of the problem>

    DESCRIPTION: <Detailed description of the problem>
                 <If you need to add enclosures, you will be instructed to
                  do so below (ENCL, ENCL1 etc.)>

    MEASURES:

- Add enclosures, if any.

- Click "Save as new TR".

- At "Actions", select "Register".
- Click "Execute".

- If no enclosures have been added to the TR, a popup window with the text
  "No enclosures have been added to the TR." will appear.
  Click OK, if you do not want to add enclosures, or click cancel if you want
  to add enclosures (add enclosure(s) and then proceed below).

- In the "Register" window, select the proper MHO (e.g. EAB-TSP-CS) and then
  click "Execute".

- If you know who should handle this TR, at "Actions", select "Assign to
  Handler".
- Click "Execute".

- In the "Assign To Handler" window, select the valid user to assign the TR to
  and then click "Execute" (at the bottom of the window).

- Verify that the "Status" field is set to "Analysis Started" and that the
  correct owner is stated in the "Owner" field.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check your TR worklist
 (Updated: 2005-03-15)

- Open MHWeb.

(- In the lower left hand "RACF Login" column, log in using your RACF password.)

- In the left hand "Tools" column, click "Worklist".

- In the opened "Worklist" page, select the following:
    MHO:         EAB-TSP-CS
    Object type: TR
    Worklist:    Handler (TRW+CORRW)
  Click "Fetch".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Additional trouble report info
 (Updated: 2005-05-04)

- TSP Trouble Report guideline for TR issuers

- TSP Product Maintenance TR processes

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Contents - TR info for TSP 5.0 and earlier
 (Updated: 2002-12-12)

General
TR status flow
Open TRtool
Set your personal TRtool default properties
Write a trouble report on a product or a document
View a TR
Assign/Answer a TR
Search for TRs using special search conditions
List all TRs issued to MHO "EAB-TSP-CS"
Filling in the Priority field
Cut and paste from Linux into TR tool

== == == == == == == == == == == == == == == == == == == == == == == == == ==

General
 (Updated: 2005-03-01)

TRtool was replaced by MHWeb at the end of 2004.
Therefore, replace all occurances of "TRtool" with "MHWeb" when following the
instructions below.

TRtool should be used to report problems found in the following TSP products
(including reporting documentation faults and also suggestions for
improvements):

- JAP 3.0 Runtime   LZN901 0141/1 R1B  (TelORB R14)
- JAP 3.0 SDK       LZN901 0140/1 R2A  (TelORB R14)
- TSP 4.0 Runtime   APR901 268/3  R3B  (TelORB R14-Linux)
- TSP 4.0 SDK API   CRA119 741/1  R1E  (TelORB R14-Linux)
- TSP 4.0 SDK SDK   CRA119 760/1  R1E  (TelORB R14-Linux)
- TSP 4.0 SDK Vega  CRA119 761/1  R2C  (TelORB R14-Linux)
- TSP 5.0 Runtime   APR901578/1   R1A  (TelORB R15)

The old trouble report handling system, ClearDDTS, should not be used for the
above stated TSP products (from Nov 1, 2002).
However, ClearDDTS should still be used for earlier TSP releases.

Note: The instructions below are tailor-made for TSP designers and testers at
      the EAB CW/OS lab, but most parts are also applicable to other TRtool
      users.


Official TRtool documents can be found at the following locations:

    - TRtool User's Guide
    - MHWeb (Web based tool to e.g. search through TRs)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

TR status flow
 (Updated: 2003-10-21)



The resolution of this image is not good, but it is the best I can do for now.

To see the image in its original context,
see TRtool User's Guide, chapter 8 (TR Status Flow).

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Open TRtool
 (Updated: 2002-12-10)

1. Open APStools from your workspace menu as follows:
   - UAB Workspace --> APStools --> APSsystem 4.1 Rev O (System Default)

2. Open TRtool from the opened window "tbxtool...":
   - Single or double click the button "TRtool" (depending on your
     TBXtool Properties settings).
        (Disregard the extra "tbxtool" window that opens.)

The first time you open TRtool, you should set your personal TRtool default
properties. To do this, see Set your personal TRtool default properties below.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Set your personal TRtool default properties
 (Updated: 2003-10-03)

This procedure only has to be performed the first time you use TRtool.

1. Open TR tool, as described in Open TRtool above.

2. In the TRtool window "TRtool:LZY...":
   - Click "Properties...".

3. In the opened window "TRtool:Tool Properties":
   - Select "Default Values" in the upper left corner, if not already selected.
   - Set "Default MHO" to "EAB-TSP-CS" (previously EAB-TSP) (by
      right-clicking the square).
   - Set "Default Worklist" to "TRW (std)" (by right-clicking the square).
   - Click "Apply".
   - Quit the window "TRtool:Tool Properties".

You have to re-open TRtool for your personal TRtool default properties to take
effect.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Write a trouble report on a product or a document
 (Updated: 2003-06-05)

1. Open TR tool, as described in Open TRtool above.

2. In the TRtool window "TRtool:LZY...":
   - Make sure "Current MHO" and "Current Worklist" are set to
     "EAB-TSP-CS (Expert)" (previously EAB-TSP) and e.g. "TRW (std)",
     respectively.
     If not, set your personal TRtool default properties, as described above. 
   - Click "Create new..." to create a new TR.

3. In the opened window "TRtool: Create new Trouble Report":
   - Select "AXE10" (which is valid also for TSP).
   - Select "Product" or "Document" depending on what you are writing this
     TR on.
     Note: For TRs on documents, not all the fields below have to be filled in.
           However, the "Document"-field and the belonging "Revision"-field have
           to be filled in (e.g. "4/1553-APR 901 268/3 UEN" and "B",
           respectively).
   - Click "Create...".

4. In the opened window "TRtool:Description ( AXE10 )", all fields specified
   in bold writing in the tables below must be filled in.
   Most items are available from respective list by right-clicking the square
   next to the field of interest.
   If the list is empty or does not have the required input string, the field
   has to be entered manually.

   Enter the following:

Heading:	Describe the problem on a slogan level. TSP 5.0: CW/OS subsystem test should start the line with e.g. "cwos503:"   (Do not use the list contents)
Priority:	A, B or C (See Filling in the Priority field below)   (Use the list contents by right-clicking the square)
ISP (Customer):	N   Not ISP Fault (Not affecting In Service Performance)   (Use the list contents by right-clicking the square)
Customer:	JAP 3.0 & TSP 4.0: UNDEF TSP 5.0: TSPSST   (Enter this manually, i.e. do not use the list contents (to save time))
Market Ref: Only valid for TSP 5.0	TSP5-CWOS-SST   (Use the list contents by right-clicking the square)
Country Code: Only valid for TSP 5.0	SE   (Use the list contents by right-clicking the square)
Site: Only valid for TSP 5.0	AS   (Automatically filled in when selecting "Country Code" above)
Site Status:	Select the appropriate item from the list (e.g. TEST).   (Not mandatory, but recommended)

   Thereafter, manually enter one of the Products (Product identities), which
   correspond to the valid release, specified in the table below. (The product
   identities are not available from the Product list in TRtool.)
   If you right-click the square next to the Product field, you may get a list
   of revisions to choose from for the R-state field. If not, the R-state field
   has to be entered manually. See table below.
   Then right-click the square next to the Designation field to automatically
   get the Designation field information belonging to the Product. See table
   below.

Release:	Product:	R-state:	Designation:
JAP 3.0 Runtime (R14)	LZN 901 0141/1	R1B *	TELORB RUNTIME
JAP 3.0 SDK (R14)	SDK LZN 901 0140/1	R2A *	TELORB SDK & API
TSP 4.0 Runtime (R14-Linux)	APR 901 268/3	R3B *	CLUSTERWARE/OS
TSP 4.0 SDK API (R14-Linux)	SDK API CRA 119 741/1	R1E *	CLUSTERWARE/OS API
TSP 4.0 SDK SDK (R14-Linux)	SDK SDK CRA 119 760/1	R1E *	CLUSTERWARE/OS SDK
TSP 4.0 SDK Vega (R14-Linux)	SDK Vega CRA 119 761/1	R2C *	VEGA
TSP 5.0 (R15)	APR 901 578/1	R1A *	CLUSTERWARE/OS

(*) The R-state values specified in the table above are for the patch
versions of the stated products which were valid when I last updated this
section. To be sure that you use the correct R-state for the TR you are
writing, consult the following page where all products and their revisions
for different patch releases are specified:
Testbed <-> CM/RM Mapping.
  (Old link: Testbed <-> CM/RM Mapping)

   For TSP 5.0, AS/SS System and its corresponding R-state also have to be
   entered according to the table below.

AS/SS System: Only valid for TSP 5.0	R-state: Only valid for TSP 5.0
ANA 901 03/2	R4A

   (More R-state info for TSP 5.0, LSV511 can be found in TSP and TADE,
    respectively.)

   The Additional Info field also has to be entered according to the table below.

Additional Info:

Specify the release/patch level that the fault is reported on, e.g. "TSP 5.0 LSV503", "R14lp5" (TSP 4.0 patch 5) or "R14p19" (JAP 3.0 patch 19). To check which CM/RM a patch is released in, see Testbed <-> CM/RM Mapping.

   - Altogether you should have entered 9 (JAP 3.0 & TSP 4.0) or 14 (TSP 5.0) input
     fields. Verify this.

   - Click "Update". (The TR gets an "Ericsson Ref" identity (TR number) and
                      it is set to "Status: Private". You will shortly receive
                      an e-mail containing this information.)

   - Select "View" --> "Observations..." 

5. In the opened window "TRtool:Observation for...":
   - Fill in the Trouble Effect, Trouble Description (and Measures) fields.

   - Preferably (if applicable), add two new headings, named e.g.
        4   S Y S T E M   C O N F I G U R A T I O N
     and
        5   T R A F F I C   S E T U P
     and add information about how the system was configured and how the traffic
     was setup when the fault occurred.

     (TRtool will not accept more than 1000 rows for Observation, so if your
      information will exceed 1000 rows, store some of the information, e.g.
      log printouts, as an enclosure instead of trying to squeeze it in (see
      instructions for how to do this in step 6 below, but complete this step
      first)).

   - Click "Update".  (The text "Updating Trouble Report ... Done."
                       will appear in the lower left corner.)
   - Quit the window "TRtool:Observation for...".

6. If applicable, add an enclosure containing log printouts, error dumps,
   crashcollector files, etc, as follows (if not, skip to step 7):
   - Create a separate file (or several files) containing the additional
     information (in your personal home directory or where you have opened
     TRtool from).
       (The file contents will be attached to your TR in the next steps).

   - In the window "TRtool:Description ( AXE10 )":
     - Select "View" --> "Enclosures..."

   - In the opened window "TRtool:Enclosures...":
     - Select "File" --> "Register..."

   - In the opened window "TRtool:Register Trouble Report Enclosure":
     - Select the file(s) to be enclosed from the list of files.
     - Either, if you want to enclose a pure textfile (to be able to easily
       browse it in MHWeb):
         Select "File contents: ASCII" and "Register mode: Text".
       or, if enclosing a non-text file, e.g. a crashcollector file:
         Select "File contents: Binary" and "Register mode: Binary" (default).
     - Click "Register".
     - Click "OK" in the pop-up window.
     - Quit the window "TRtool:Register Trouble Report Enclosure".

   - In the opened window "TRtool:Enclosures...":
     - Click "Refresh" (to check that the enclosure is registered).
     - Quit the window "TRtool:Enclosures...".

7. Update and register the TR by doing the following in the window
   "TRtool:Description ( AXE10 )":
   - Click "Update".   (The text "Updating Trouble Report ... Done."
                        will appear in the lower left corner.)
                       ("Enclosures:" may still show NONE, even if an
                        enclosure has been registered for this TR.)
   - Click "Register". (The text "Executing action Register ... Done."
                        will appear in the lower left corner.)
                       (This action makes the TR official.)
                       ("Status:" will be changed to "Registered".)

8. If you want to assign the TR to a designer right away, do as follows
   (if not, skip to step 9):
   - Click "Transfer..." in the window "TRtool:Description ( AXE10 )".

   In the opened window "TRtool:Transfer...":
   - Select "Actions:" --> "Assign to Handler", by right-clicking the
     square next to "Actions".
   - Select Handler to assign the TR to from the scroll-list.
   - Click "Execute Action".  ("Status:" will be changed to "Analysis
                               Started")
     - Quit the window "TRtool:Transfer...".

9. Quit TRtool as follows:
   - Quit the window "TRtool:Description ( AXE10 )".
   - Quit the window "TRtool:LZY...".
   - Quit the window "tbxtool...".


The TR writing is now completed and you can now relax and have forty winks.


Hint:
If you want to modify a TR after it has been registered and the status of the
TR is still "Registered", do as follows (you will keep the TR number):
  - Click "Transfer..." in the window "TRtool:Description ( AXE10 )".

  In the opened window "TRtool:Transfer...":
  - Select "Actions:" --> "Reject", by right-clicking the
    square next to "Actions".
  - Add information about the reject reason in the white input field.
  - Click "Execute Action".  ("Status:" will be changed to "Private
                                                                  (Rejected)")
  Modify the TR, e.g. "Additional Info", "Observations" (Click "Update"), etc.

  - Click "Update".
  - Click "Register" ("Status:" will be changed to "Registered".)

  - Quit the window "TRtool:Transfer...".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

View a TR
 (Updated: 2003-10-23)

If you want to view a TR, I suggest you to use MHWeb and select
"TR" --> "TR Search".

To use TRtool to view and/or update a TR, start as follows:

1. Open TR tool, as described in Open TRtool above.

2. In the TRtool window "TRtool:LZY...":
   - Fill in "E-Ref:" with the TR number to be opened (e.g. HD62751).
   - Select "File" --> "Load E-Ref..." (or just enter Enter).

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Assign/Answer a TR
 (Updated: 2004-01-08)

To use TRtool to assign/answer a TR, do as follows:

1. Open TR tool, as described in Open TRtool above.

2. In the TRtool window "TRtool:LZY...":
   - Fill in "E-Ref:" with the TR number to be opened (e.g. HD62751).
   - Select "File" --> "Load E-Ref..." (or just enter Enter).

   TRtool:Description:
     Transfer...

   TRtool:Transfer:
     Actions: Assign to Handler
     Select Handler
     Execute Action
     Status: Analysis Started

   TRtool:Proposal:
     Actions: Proposal
     View --> Proposal
       (When the TR has been analyzed and the designer is convinced that a
       correction is needed, the TR should/will be set to PP (Proposal), as
       soon as possible.)

   TRtool:Transfer:
     Actions: Answer
     View --> Answer...

   TRtool:Answer:
     Answer Code:   Recommended value when a correction is made:
                      B11  To be corrected in later issue of the Source system

                    Recommended values when no correction is made:
                      AnswerCode: D1-D7

     Fault Code:    Example value when a correction is made:
                      232: Programming fault. Coding fault.

                    Recommended value when no correction is made:
                      FaultCode: 239

     ISP (Design):  Recommended value:
                      N    Not ISP Fault (Not affecting In Service Performance

     In the white input field (for "Implementation information") specify the
     following information (Only valid when a correction is made):

                    - Which MIs you have delivered to which testbeds.
                    - The revisions of the delivered MIs.

                    Example:
                      Delivered the following to tbAD15, tbAD14lp8, tbAD14p21:
                      OU/DXXX R1A06
                      LM/DXX

     (... and don't forget the input field for "Actual Delivery Package". (Only
      for CCQ?))

     Update
     Transfer...   or quit TRtool:Answer window and continue in the
                          previously opened TRtool:Transfer window.

   TRtool:Transfer:
     Actions: Answer
     Execute Action
     Actions: Accept
     Execute Action
     Status: Follow Up

3. If you want to change the status to Finished, do as follows:

   TRtool:Transfer:
     Actions: Finish
     Execute Action
     Status: Finished

  - Quit the opened windows.

-- -- -- -- -- -- -- -- -- -- -- --

Assign a TR to the hardware department
--------------------------------------

(Example: Write the TR on e.g. TSP 4.0, but set Additional info to e.g. NSP4.1.)

Transfer...

   TRtool:Transfer:
     Actions: Transfer to MHO
     Transfer to MHO: EAB-TSP-HW
     (Comments: Assign this TR to uabrosm for him to assign it further)
     Execute Action

     Status: Registered

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Search for TRs using special search conditions
 (Updated: 2002-12-10)

I prefer to use MHWeb to search for specific TRs.
TRtool instructions for searching for TRs can be found below the MHWeb
instructions.

Search for TRs using MHWeb
--------------------------

- Open MHWeb.
- Click "TR" -> "TRSearch".
- Enter one or several of the examplified search conditions below.

    Market Ref:        TSP5-CWOS-SST-*             (for TSP 5.0)
    Heading:           Interrupt 14
    Designation:       Clusterware/OS       (Note: Non-capital for "lusterware")
    Product Number:    "    / APR 901 268 / 3"     (for TSP 4.0)
    Product Number:    "    / APR 901 578 / 1"     (for TSP 5.0)
    Product Revision:  R1A                         (for TSP 5.0)
    Status:            ALL


Search for TRs using TRtool
---------------------------

The instructions below are not yet verified.

Prerequisite:
If you do not have an own worklist, this must be created as follows:

1. Open TR tool, as described in Open TRtool above.

2. In the TRtool window "TRtool:LZY...":
   - Select "Worklist" --> "Column Editor...". (Use right mouse button)

3. In the opened window "Trtool:Worklist Layout Editor":
   - Select "File" --> "New".
   - Select "Edit" --> "Copy From" --> "TRW (std)".
   - Select "File" --> "Save as...".

4. In the opened window "TRtool:Save Worklist":
   - Specify a "Worklist Name".
   - Click "Save".
   - Quit the window "TRtool:Save Worklist".

Search for TRs using special search conditions:

1. Open TR tool, as described in Open TRtool above.

2. In the TRtool window "TRtool:LZY...":
   - Select "Current Worklist" --> <your_own_worklist>. (Use right mouse button)
   - Select "Worklist" --> "Search Conditions...".

3. In the opened window "TRtool: Search for TRs which meet...":
   - Select Product "Like" by right-clicking the square next to "Product".
   - Enter the Product identity, e.g. "APR  901  268  3" for TSP 4.0.

Hints:
  Search for TRs issued for TSP 4.0:
    ANA90103/2, APR901268/3, CRA119741/1, CRA119760/1, CRA119761/1

  Search for TRs issued for JAP 3.0:
    ANA90102/1, ANA90102, LZN9010140/1, LZN9010140, LZN9010141/1, LZN9010141

== == == == == == == == == == == == == == == == == == == == == == == == == ==

List all TRs issued to MHO "EAB-TSP-CS"
 (Updated: 2003-06-05)

1. Open TR tool, as described in Open TRtool above.

2. In the TRtool window "TRtool:LZY...":
   - Select "Current Worklist" --> "TRWE (std)". (Use right mouse button)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Filling in the Priority field
 (Updated: 2002-11-27)

Major Faults
------------

  Priority A (critical, corresponds to ClearDDTS severity 1):

  - The system reloads (zone reload).

  - There is an inconsistent state in the system
     (if an error occcurs during an operation, it shall
      be possible to either continue the operation or to
      restart the operation. The system has entered an
      inconsistent state, if none of these alternatives
      is possible).

  - There is an inconsistent state in the database.

  - A processor is hanging.

  - A function on the system level cannot be performed,
    an example would be system upgrade.

  (TRtool: A  4 W, Major fault: complete system failure, serious losses)


  Priority B (stopping, corresponds to ClearDDTS severity 2):

  - A processor reloads.

  - A function on a lower level than the system level can
    not be performed. 

  (TRtool: B  7 W, Major fault: large/small restart, traffic disturbance)


Minor Faults, Opinions and Enhancements
---------------------------------------

  Priority C (inconvenient, corresponds to ClearDDTS severity 3 & 5):

  - There is an error but the user of the application can perform
    the function.

  - Suggestions for improvements.

  (TRtool: C  3 M, Minor fault or opinion: no traffic disturbance)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Cut and paste from Linux into TR tool
 (Updated: 2003-01-07, Source: Keyhan Hadjari)

Below, you'll find a procedure for how to cut and paste text into TRtool from
Linux applications.
 
1. Highlight the text you want in Linux (probably Mozilla or Netscape).
2. Do Ctrl-c to copy the text to buffer.
   (The buffer size is limited, so you may have to copy the text page by page).
   (Just highlighting the text will not work.)
3. Go to the TRtool window, where you want to paste the text, right click and
   choose Edit -> Paste.
 
This procedure has been verified using RedHat 8.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Old trouble reporting tools
 (Updated: 2005-10-24)

- Trouble reporting software using TRtool (Should no longer be used):
  TRtool instructions.

- Trouble reporting software using ClearQuest (Should no longer be used):
  ClearQuest  (Instructions).

- Trouble reporting software using ClearDDTS (Should no longer be used):
  Log in as EAB user or as RACF user.

General
 (Updated: 2001-11-29)

ECHO (Ericsson Complaint Handling Operation) is an Ericsson corporate web tool
for fast and safe handling of complaints.

When using ECHO to fault report e.g. hardware, only officially released hardware
can be fault reported, i.e. hardware with revision R*, which have been ordered
from FC Linköping.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Complaint procedure
 (Updated: 2002-01-07)

1. Log in to ECHO via Ericsson's web page for complaints:
   http://echo.ericsson.se

   If you are not registered as an ECHO user, send an e-mail to the e-mail
   address specified on the ECHO web page.
   Once the registration order is sent, it will take less than a day to be
   registered (for me, it took approximately 30 minutes).

2. Create a complaint:
     Create complaint---> New

3. Fill in product number, serial number and order number.

   The order number is unique for each order and refers to FC Linköping's
   order number, not the order number in ClickToBuy.
   E.g. for the JAP 3.0 expansion cabinet, the following order number is valid:
   LE56588.

4. Send the complaint to FC-SCSA. (It is enough to write this as an e-mail
   address in ECHO.)

5. Within a week, you will be notified, and perhaps also receive replacement
   hardware.

Upon request, send the faulty hardware to:
  Solectron Sweden AB
  Attn. NPC Helpdesk
  Box 370
  Odenskogsvägen 27-29
  831 25 Östersund
  Sweden

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Useful data when trouble reporting a hardware board
 (Updated: 2004-08-24)

= = = = = = = = = = = = = = = = = = = = = = = =
DATA
= = = = = = = = = = = = = = = = = = = = = = = =

Board:
------
Identity:       PMD
Product number: ROJ 208 448/1 R2A
Date:           2003 10 24
Serial number:  X926003971

System:
-------
Identity:       TSP4.1
Product number: BFE 306 058/3 R2A
Date:           03W46
Serial number:  A0630300201

Cabinet:
--------
Identity:       NSP4.1
Product number: 2/BFE 306 058/3 R1A
Date:           03W46
Serial number:  A0630300202

Various:
--------
Date:           2005 06 04
Tester:         Andreas Johansson, uabadas, 851 3945


= = = = = = = = = = = = = = = = = = = = = = = =
Problem
= = = = = = = = = = = = = = = = = = = = = = = =

This board was working fine until mid May 2004. Suddenly it was a problem with
the BIOS. When showing the board to your "HW guys" they discovered that it was
a problem with the hard disk, which did not start as it should.

So, most likely it is some problem with the hard disk.

(Source: E-mail from Andreas Johansson, 2004-07-08)

-- -- -- -- -- -- -- -- -- -- -- -- -- --

Hi Christer,

I've detected a faulty SCB board in the to11 system in the
CW/OS TSP lab in the yellow building, and I would like to have
this board replaced.

My question is: Who can I give the faulty SCB board to,
to get a replacement board?

This board was working fine until end June 2004. Suddenly, the
board stopped functioning. During an initial installation, all
processor boards, located in the same magazine as the faulty
SCB board, got the following printout on a serial terminal:
"Failed to detect all internal interfaces ! Detected 1 of 2."

So, most likely, one of the interfaces on the SCB works, but
the other does not.

Board data
----------
Identity:       SCB-RP
Product number: ROJ 208 423/2 R4A
Date:           2003 10 27
Serial number:  TF11270948

Brgds,
EAB/UKG/OV Michel Sundin

(Source: E-mail from Michel to christer.tibeus@ericsson.com, 2004-07-08)

TSP systems used by CW/OS subsystem test
NSP 4.0
-------

  to27 (Micro, 8 TPs, no DVD/tape drive)
    to27io1:              134.138.187.109
    to27io2:              134.138.187.110
    VIP address:          172.30.14.27
    VIP router ranges:    192.168.76.60-79
                          192.168.77.60-79
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.61
                          192.168.77.62
    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.2

  to28 (Mini, 18 TPs, no DVD/tape drive)
    to28io1:              134.138.187.113
    to28io2:              134.138.187.114
    VIP address:          172.30.14.28
    VIP router ranges:    192.168.76.80-99
                          192.168.77.80-99
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.80
                          192.168.77.81
    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.2

  to29 (Mini, 18 TPs, DVD/tape drive) (Actually Maxi)
    to29io1:              134.138.187.60
    to29io2:              134.138.187.61
    VIP address:          172.30.14.29
    VIP router ranges:    192.168.76.100-119
                          192.168.77.100-119
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.100
                          192.168.77.101
    VIP gateways
      (IP to GW):         192.168.76.2
                          192.168.77.1

NSP 4.1
-------

  to3 (Maxi/Midi?, 39 TPs, DVD/tape drive)
    to3io1:               134.138.187.20
    to3io2:               134.138.187.21
    VIP address:          172.30.14.3
    VIP router ranges:    192.168.76.xx-yy
                          192.168.77.xx-yy
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.162
                          192.168.77.163
                          192.168.77.164
                          192.168.76.165

    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.1
                          192.168.77.2
                          192.168.76.2

  to11 (Maxi, 19 TPs, DVD/tape drive)
    to11io1:              134.138.187.44
    to11io2:              134.138.187.45
    VIP address:          172.30.14.11
    VIP router ranges:    192.168.76.200-209
                          192.168.77.200-209
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.200
                          192.168.77.201
    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.2

  to13 (Maxi, 40 TPs, DVD/tape drive)
    to13io1:              134.138.187.58
    to13io2:              134.138.187.59
    VIP address:          172.30.14.13
    VIP router ranges:    192.168.76.120-139
                          192.168.77.120-139
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.120
                          192.168.76.121
                          192.168.77.120
                          192.168.77.121
    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.2

  to15 (Maxi, 19 TPs, DVD/tape drive)
    to15io1:              134.138.187.56
    to15io2:              134.138.187.57
    VIP address:          134.138.71.15
    VIP router ranges:    192.168.76.180-189
                          192.168.77.180-189
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.180
                          192.168.77.181
    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.2

  to23 (Maxi, 40 TPs, DVD/tape drive)
    to23io1:              134.138.187.95
    to23io2:              134.138.187.96
    VIP address:          172.30.14.23
    VIP router ranges:    192.168.76.40-59
                          192.168.77.40-59
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.40
                          192.168.77.41
    VIP gateways
      (IP to GW):         192.168.76.2
                          192.168.77.1

NSP 5.0
-------

  to2 (Midi, 19 TPs, DVD/tape drive)
    to2io1:               134.138.187.17
    to2io2:               134.138.187.18
    VIP address:          172.30.14.2
    VIP router ranges:    192.168.76.70-zz
                          192.168.77.70-zz
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.70
                          192.168.77.70
    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.2

  to14 (Midi, 44 TPs, DVD/tape drive)
    to14io1:              134.138.187.54
    to14io2:              134.138.187.55
    VIP address:          172.30.14.14
    VIP router ranges:    192.168.76.170-179
                          192.168.77.170-179
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.170
                          192.168.77.171
    VIP gateways
      (IP to GW):         192.168.76.2
                          192.168.77.1

  to20 (Micro, 9 TPs, DVD/tape drive)
    to20io1:              134.138.187.89
    to20io2:              134.138.187.90
    VIP address:          172.30.14.20
    VIP router ranges:    192.168.76.xx-yy
                          192.168.77.xx-yy
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.138
                          192.168.77.139
    VIP gateways
      (IP to GW):         192.168.76.1
                          192.168.77.2

  to21 (Midi, 43 TPs, DVD/tape drive)
    to21io1:              134.138.187.91
    to21io2:              134.138.187.92
    VIP address:          172.30.14.21
    VIP router ranges:    192.168.76.190-199
                          192.168.77.190-199
    VIP interfaces
      actually used
      (IP of eth):        192.168.76.190
                          192.168.77.191
    VIP gateways
      (IP to GW):         192.168.76.2
                          192.168.77.1

Previous systems (some existing and some non-existing)
----------------

  to1 (uabeber's nightly building system)
     to1io1              134.138.187.14
     VIP (eth2):         192.168.76.150-159
     VIP (eth3):         192.168.77.150-159

  TelORB system to5
     VIP (eth2):         192.168.76.140-149
     VIP (eth3):         192.168.77.140-149

  TelORB system to6
     VIP (eth2):         192.168.76.210-219
     VIP (eth3):         192.168.77.210-219

  TelORB system to9 (6 350 MHz PC, 256M memory) (Education site)
     Traffic network A:  134.138.69
     Traffic network B:  134.138.71
     to9io1:             134.138.187.38  (Linux)
     to9io2:             134.138.187.39  (Linux)
     to9ts:              134.138.187.40

  TelORB system to10 (21 Ziatech Pentium I)
     Traffic network A:  134.138.61 (0-127)
     Traffic network B:  134.138.62 (0-127)
     EthA (base):        134.138.61.20
     EthB (base):        134.138.62.20
     EthA (expansion):   134.138.61.21
     EthB (expansion):   134.138.62.21
     to10io1:            134.138.187.47
     to10io1i1:          134.138.61.25
     to10io1i2:          134.138.62.25
     to10io2:            134.138.187.48
     to10io2i1:          134.138.61.26
     to10io2i2:          134.138.62.26
     TP1-89 (network A): 134.138.61.31-119
     TP1-89 (network B): 134.138.62.31-119
     to10ts:             134.138.187.49  (Not installed)
     to10s7c1 (AXmp1):   134.138.61.23
                         134.138.62.23
     to10s7c2 (AXmp2):   134.138.61.24
                         134.138.62.24
     RMS:                134.138.62.22

     Old settings before network split:
     Traffic network A:  134.138.61
     Traffic network B:  134.138.62
     EthA (base):        134.138.61.20
     EthB (base):        134.138.62.20
     EthA (expansion):   134.138.61.21
     EthB (expansion):   134.138.62.21
     to10io1:            134.138.187.47
     to10io1i1:          134.138.61.25
     to10io1i2:          134.138.62.25
     to10io2:            134.138.187.48
     to10io2i1:          134.138.61.26
     to10io2i2:          134.138.62.26
     TP1- (network A):   134.138.61.101-
     TP1- (network A):   134.138.62.101-
     to10ts:             134.138.187.49  (Not installed)
     to10s7c1 (AXmp1):   134.138.61.40
                         134.138.62.40
     to10s7c2 (AXmp2):   134.138.61.41
                         134.138.62.41
     RMS:                134.138.62.22

  TelORB system to12
     Traffic network A:  134.138.65
     Traffic network B:  134.138.66
     to12io1:            134.138.187.50
     to12io2:            134.138.187.51

  TelORB system to22
     VIP address:  172.30.14.22 (Old: 134.138.71.22)
     IP addresses: 192.168.76.20 - 192.168.76.39 (eth2)
                   192.168.77.20 - 192.168.77.39 (eth3)

  TelORB system to100 (14 Ziatech Pentium I) (Located at HW department)
     Traffic network A:  134.138.81     (Not connected to Pink LAN)
     Traffic network B:  134.138.82     (Not connected to Pink LAN)
     to100io1:           134.138.187.1
     to100io2:           134.138.187.2

  TelORB system to101 (21 Ziatech Pentium I) (Located at HW department)
     Traffic network A:  134.138.81     (Not connected to Pink LAN)
     Traffic network B:  134.138.82     (Not connected to Pink LAN)
     to101io1:           134.138.187.41
     to101io2:           134.138.187.42

  TelORB system teodor (7 Ziatech Pentium I) (Located in Demo room)
                         Prior to usage, contact John Vaksdal.
     Traffic network A:  134.138.xx
     Traffic network B:  134.138.yy
     to12io1:            134.138.187.52
     to12io2:            134.138.187.53

  Common data for all systems:
  Subnetmask:      255.255.248.0
  Default gateway: 134.138.184.1
  DNS-server1:     134.138.201.17
  DNS-server2:     134.138.226.13
  Default domain:  uab.ericsson.se 

More info can be retrieved at Lab Booking.

-   -   -   -   -   -

Low                                 High
---                                 ----
IO1: 25                             IO1: 225
IO2: 26                             IO2: 226
TP:  31-                            TP:  131-
Switch in base cabinet:      20     Switch in base cabinet:      220
Switch in expansion cabinet: 21     Switch in expansion cabinet: 221


Previously used TelORB systems by CW/OS subsystem test
TelORB system to1 (8 ppro, 512M memory)
   Traffic network A:  134.138.72
   Traffic network B:  134.138.75
   to1io1:             134.138.187.14  (Sparc 5) (hme0)
   to1io2:             134.138.187.15  (Sparc 5) (hme0)
   to1ts:              134.138.187.16

TelORB system to2 (12 Pentium II)
   Traffic network A:  134.138.73
   Traffic network B:  134.138.78
   to2io1:             134.138.187.17  (Linux)
   to2io2:             134.138.187.18  (Linux)
   to2ts:              134.138.187.19

TelORB system to3 Nora (7 Ziatech Pentium I) (System powered off)
                  Also see
                  Detailed description of IP addresses for TelORB system to3.
   Traffic network A:  134.138.70 (0-127) (Low)
   Traffic network B:  134.138.74 (0-127) (Low)
   EthA (base):        134.138.70.20
   EthB (base):        134.138.74.20
   EthA (expansion):   134.138.70.21
   EthB (expansion):   134.138.74.21
   to3io1:             134.138.187.20
   to3io1i1:           134.138.70.25
   to3io1i2:           134.138.74.25
   to3io2:             134.138.187.21
   to3io2i1:           134.138.70.26
   to3io2i2:           134.138.74.26
   TP1-89 (network A): 134.138.70.31-119
   TP1-89 (network B): 134.138.74.31-119
   to3ts:              134.138.187.22  (134.138.25.131)
   RMS:                None

   Old settings before network split:
   Traffic network A:  134.138.70
   Traffic network B:  134.138.74
   to3io1:             134.138.187.20
   to3io2:             134.138.187.21
   to3ts:              134.138.187.22

TelORB system to4 (8 Sparc)
   Traffic network A:  134.138.17
   to4io1:             134.138.187.23
   to4io2:             134.138.187.24
   to4ts:              134.138.187.25

TelORB system to5 (5 ppmx, 192M memory)
   Traffic network A:  134.138.19
   Traffic network B:  134.138.79
   to5io1:             134.138.187.26  (Linux)
   to5io2:             134.138.187.27  (Not availabale yet)
   to5ts:              134.138.187.28

TelORB system to6 Nora (7 Ziatech Pentium I)
   Traffic network A:  134.138.70 (128-255)
   Traffic network B:  134.138.74 (128-255)
   EthA (base):        134.138.70.220
   EthB (base):        134.138.74.220
   EthA (expansion):   134.138.70.221
   EthB (expansion):   134.138.74.221
   to6io1:             134.138.187.29
   to6io1i1:           134.138.70.225
   to6io1i2:           134.138.74.225
   to6io2:             134.138.187.30
   to6io2i1:           134.138.70.226
   to6io2i2:           134.138.74.226
   TP1-89 (network A): 134.138.70.131-219
   TP1-89 (network B): 134.138.74.131-219
   to6ts:              134.138.187.31  (134.138.25.140)
   RMS:                None

   Old settings before network split:
   Traffic network A:  134.138.76
   Traffic network B:  134.138.77
   to6io1:             134.138.187.29
   to6io2:             134.138.187.30
   to6ts:              134.138.187.31

TelORB system to7 (28 Ziatech Pentium I) (System crapped)
   Traffic network A:  134.138.67
   Traffic network B:  134.138.68
   to7io1:             134.138.187.32
   to7io2:             134.138.187.33
   to7ts:              134.138.187.34

TelORB system to8 (28 Ziatech Pentium I) (System scrapped)
   Traffic network A:  134.138.81
   Traffic network B:  134.138.82
   to8io1:             134.138.187.35
   to8io2:             134.138.187.36
   to8ts:              134.138.187.37

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Detailed description of IP addresses for TelORB system to3
Data not updated after split of networks!!!

IO processor 1:
  134.138.187.20  (to3io1, external connection from IO1 to 134.138.187, hme0)
  134.138.70.25   (to3io1i2, internal connection from IO1 to Ethernet Switch A, exp0)
  134.138.74.25   (to3io1i3, internal connection from IO1 to Ethernet Switch B, exp1)

IO processor 2:      
  134.138.187.21  (to3io2, external connection from IO2 to 134.138.187, hme0)
  134.138.70.26   (to3io2i2, internal connection from IO2 to Ethernet Switch A, exp0)
  134.138.74.26   (to3io2i3, internal connection from IO2 to Ethernet Switch B, exp1)

Terminal server: 
  134.138.187.22  (to3ts)

Ethernet switch A:
  134.138.70.20   (EthA)      (Traffic network A: 134.138.70)

Ethernet switch B:
  134.138.74.20   (EthB)      (Traffic network B: 134.138.74)

TelORB processors:
  TelORB processor 1   134.138.70.101  (via Ethernet Switch A)
  TelORB processor 1   134.138.74.101  (via Ethernet Switch B)
  TelORB processor 2   134.138.70.102  (via Ethernet Switch A)
  TelORB processor 2   134.138.74.102  (via Ethernet Switch B)
  TelORB processor 3   134.138.70.103  (via Ethernet Switch A)
  TelORB processor 3   134.138.74.103  (via Ethernet Switch B)
  TelORB processor 4   134.138.70.104  (via Ethernet Switch A)
  TelORB processor 4   134.138.74.104  (via Ethernet Switch B)
  TelORB processor 5   134.138.70.105  (via Ethernet Switch A)
  TelORB processor 5   134.138.74.105  (via Ethernet Switch B)
  TelORB processor 6   134.138.70.106  (via Ethernet Switch A)
  TelORB processor 6   134.138.74.106  (via Ethernet Switch B)
  TelORB processor 7   134.138.70.107  (via Ethernet Switch A)
  TelORB processor 7   134.138.74.107  (via Ethernet Switch B)

SS7 processor 1:
  134.138.70.40
  134.138.74.40

SS7 processor 2:
  134.138.70.41
  134.138.74.41

tos1 and tos2 are alpha machines that the EAB CW/OS lab systems are connected
to.
The alpha machines are used to get direct access to the IO processors.
The user remotely logs in to one of the alpha machines to e.g. run the TelORB
system building command "epct".
Two alpha machines are used for redundancy reasons.
The IP addresses of the alpha machines are as follows:
tos1	134.138.187.4
tos2	134.138.187.5

The IP address of WS client uabs31i1c47, which usually is used to control TelORB
system "to3" is 134.138.186.47


nslookup    Name:    to3io1.uab.ericsson.se
            Address: 134.138.187.20

            Name:    to3io2.uab.ericsson.se
            Address: 134.138.187.21

            Name:    to3ts.uab.ericsson.se
            Address: 134.138.187.22

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Router IP addresses
EAB CW/OS lab router (Alcatel OmniStack) (used for e.g. the communication
between network redundant zones which are connected with the router in between
them):
  134.138.17.2

The EAB CW/OS lab router is used between network redundant TelORB systems and
the speed is 100Mbit/s (?).

To test a different speed between two network redundant TelORB zones (to
simulate a customer site), a PC has been configured as a router. The TelORB
zones to14 and to15 have been connected to this PC and the speed between
these systems is currently (010322) 1,5 Mbit/s.

For to14 and to15, the PC (FreeBSD) and router configuration look as follows:

                        ~~~~~~~~~~~~~~~~~~~~~
                       | Working environment |
                        ~~~~~~~~~~~~~~~~~~~~~
                                 |
                                 |
                                 | 134.138.17.2
                    --------------------------------------
                   | EAB CW/OS lab router XYLAN OmniStack |
                    --------------------------------------
                            S3/3 | 192.168.57.2 (Internal)
                                 |
                                 |
                                 | 192.168.57.3 (Internal)
  ---------------------------------------------------------------------------
 |           PC  FreeBSD/i386 (trfShaper.uab.ericsson.se) (ttyp0)            |
  ---------------------------------------------------------------------------
     | 134.138.57.30    | 134.138.58.30    | 134.138.57.230    | 134.138.58.230
     |                  |                  |                   |
     | 134.138.57.20    |                  | 134.138.57.220    |
  -------------------   |               -------------------    |
 | to14 Eth Switch A |  |              | to15 Eth Switch A |   |
  -------------------   |               -------------------    |
                        |                                      |
          134.138.58.20 |                       134.138.58.220 |
         -------------------                    -------------------
        | to14 Eth Switch B |                  | to15 Eth Switch B |
         -------------------                    -------------------

The addresses 192.168.57.2 and 192.168.57.3 are internal addresses and should
not be accessed from the working environment.

To access the PC, use any of the IP addresses 134.138.57.30, 134.138.58.30,
134.138.57.230 or 134.138.58.230:
  telnet 134.138.57.30               (If it is not possible to log in to the PC,
                                      reboot it by pressing its reset button)
  telorb                             (Type user)
  psw                                (Type password)
  su                                 (Enter superuser mode)

Check if the pipes are up and running, and bring the pipes down and up:
  ifconfig -a
    Up   = <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
    Down = <BROADCAST,SIMPLEX,MULTICAST>
  ifconfig fxp1 down                 (Bring fxp1 down)
  ifconfig fxp1 up                   (Bring fxp1 up)

To change the speed of the configured pipes or to add more TelORB systems or
IP addresses, edit (vi) the file setupShaping in the PC. It seems as if it is
not possible to make e.g. speed changes in runtime.
The file setupShaping looks something like this, where to14 and to15 is
configured (pipes 2, 3, 6, 7 are configured for symetrical reasons, but are
probably not used, the speed is set to 1.5 Mbit/s for all pipes):
  #!/bin/sh

  # pipes from Zone 1 to Zone 2

  ipfw add pipe 1 ip from 134.138.57.0/25 to 134.138.57.128/25 out
  ipfw add pipe 2 ip from 134.138.57.0/25 to 134.138.58.128/25 out
  ipfw add pipe 3 ip from 134.138.58.0/25 to 134.138.57.128/25 out
  ipfw add pipe 4 ip from 134.138.58.0/25 to 134.138.58.128/25 out

  # pipes from Zone 2 to Zone 1

  ipfw add pipe 5 ip from 134.138.57.128/25 to 134.138.57.0/25 out
  ipfw add pipe 6 ip from 134.138.57.128/25 to 134.138.58.0/25 out
  ipfw add pipe 7 ip from 134.138.58.128/25 to 134.138.57.0/25 out
  ipfw add pipe 8 ip from 134.138.58.128/25 to 134.138.58.0/25 out

  # enable rest of the junk
  ipfw add allow ip from any to any

  # configure pipes

  ipfw pipe 1 config bw 1500Kbit/s delay 100ms
  ipfw pipe 2 config bw 1500Kbit/s delay 100ms
  ipfw pipe 3 config bw 1500Kbit/s delay 100ms
  ipfw pipe 4 config bw 1500Kbit/s delay 100ms
  ipfw pipe 5 config bw 1500Kbit/s delay 100ms
  ipfw pipe 6 config bw 1500Kbit/s delay 100ms
  ipfw pipe 7 config bw 1500Kbit/s delay 100ms
  ipfw pipe 8 config bw 1500Kbit/s delay 100ms

To activate the changes, the PC has to be rebooted by pressing its reset button.
When rebooting, the file setupShaping is executed.

Check pipe direction settings:
  ipfw list      (ipfw - controlling utility for IP firewall and traffic shaper)
    00100 pipe 1 ip from 134.138.57.0/25 to 134.138.57.128/25 out
    00200 pipe 2 ip from 134.138.57.0/25 to 134.138.58.128/25 out
    00300 pipe 3 ip from 134.138.58.0/25 to 134.138.57.128/25 out
    00400 pipe 4 ip from 134.138.58.0/25 to 134.138.58.128/25 out
    00500 pipe 5 ip from 134.138.57.128/25 to 134.138.57.0/25 out
    00600 pipe 6 ip from 134.138.57.128/25 to 134.138.58.0/25 out
    00700 pipe 7 ip from 134.138.58.128/25 to 134.138.57.0/25 out
    00800 pipe 8 ip from 134.138.58.128/25 to 134.138.58.0/25 out
    00900 allow ip from any to any
    65535 deny ip from any to any

Check which speed that is used and if anything is sent on the pipes:
  ipfw pipe list            (Check all pipes)
  ipfw pipe list 1          (Check pipe 1)
    00001:   1.500 Mbit/s  100 ms   50 sl. 1 queues (1 buckets) droptail
    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
    BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
      0 udp    134.138.57.32/1324   134.138.57.131/5666  5590  6598872  0    0   0

    Speed and delay:   1.500 Mbit/s  100 ms
    No. of bytes sent: 6598872

  NetRed traffic uses pipes 1 or 4 for replications from to14 to to15 and
  pipes 5 and 8 for replications from to15 to to14.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Conversion table for the new IP addressing scheme
The recommended internal IP addressing scheme was changed in TSP 4.0 patch 4.1
(r14lp4.1) as follows (generated by the script genGemTbl.sh):

Printing network-addresses belonging to network A and zone 1 ...
============================================================================
old ip-address		new ip-address		magazine-no	slot-no
172.16.100.100		172.16.0.32		0		0
172.16.100.101		172.16.0.1		0		1
172.16.100.102		172.16.0.2		0		2
172.16.100.103		172.16.0.3		0		3
172.16.100.104		172.16.0.4		0		4
172.16.100.105		172.16.0.5		0		5
172.16.100.106		172.16.0.6		0		6
172.16.100.107		172.16.0.7		0		7
172.16.100.108		172.16.0.8		0		8
172.16.100.109		172.16.0.9		0		9
172.16.100.110		172.16.0.10		0		10
172.16.100.111		172.16.0.11		0		11
172.16.100.112		172.16.0.12		0		12
172.16.100.113		172.16.0.13		0		13
172.16.100.114		172.16.0.14		0		14
172.16.100.115		172.16.0.15		0		15
172.16.100.116		172.16.0.16		0		16
172.16.100.117		172.16.0.17		0		17
172.16.100.118		172.16.0.18		0		18
172.16.100.119		172.16.0.19		0		19
172.16.100.120		172.16.0.20		0		20
172.16.100.121		172.16.0.21		0		21
172.16.100.122		172.16.0.22		0		22
172.16.100.123		172.16.0.23		0		23
172.16.100.124		172.16.0.24		0		24
172.16.100.125		172.16.0.25		0		25
172.16.101.100		172.16.0.160		1		0
172.16.101.101		172.16.0.129		1		1
172.16.101.102		172.16.0.130		1		2
172.16.101.103		172.16.0.131		1		3
172.16.101.104		172.16.0.132		1		4
172.16.101.105		172.16.0.133		1		5
172.16.101.106		172.16.0.134		1		6
172.16.101.107		172.16.0.135		1		7
172.16.101.108		172.16.0.136		1		8
172.16.101.109		172.16.0.137		1		9
172.16.101.110		172.16.0.138		1		10
172.16.101.111		172.16.0.139		1		11
172.16.101.112		172.16.0.140		1		12
172.16.101.113		172.16.0.141		1		13
172.16.101.114		172.16.0.142		1		14
172.16.101.115		172.16.0.143		1		15
172.16.101.116		172.16.0.144		1		16
172.16.101.117		172.16.0.145		1		17
172.16.101.118		172.16.0.146		1		18
172.16.101.119		172.16.0.147		1		19
172.16.101.120		172.16.0.148		1		20
172.16.101.121		172.16.0.149		1		21
172.16.101.122		172.16.0.150		1		22
172.16.101.123		172.16.0.151		1		23
172.16.101.124		172.16.0.152		1		24
172.16.101.125		172.16.0.153		1		25
172.16.102.100		172.16.1.32		2		0
172.16.102.101		172.16.1.1		2		1
172.16.102.102		172.16.1.2		2		2
172.16.102.103		172.16.1.3		2		3
172.16.102.104		172.16.1.4		2		4
172.16.102.105		172.16.1.5		2		5
172.16.102.106		172.16.1.6		2		6
172.16.102.107		172.16.1.7		2		7
172.16.102.108		172.16.1.8		2		8
172.16.102.109		172.16.1.9		2		9
172.16.102.110		172.16.1.10		2		10
172.16.102.111		172.16.1.11		2		11
172.16.102.112		172.16.1.12		2		12
172.16.102.113		172.16.1.13		2		13
172.16.102.114		172.16.1.14		2		14
172.16.102.115		172.16.1.15		2		15
172.16.102.116		172.16.1.16		2		16
172.16.102.117		172.16.1.17		2		17
172.16.102.118		172.16.1.18		2		18
172.16.102.119		172.16.1.19		2		19
172.16.102.120		172.16.1.20		2		20
172.16.102.121		172.16.1.21		2		21
172.16.102.122		172.16.1.22		2		22
172.16.102.123		172.16.1.23		2		23
172.16.102.124		172.16.1.24		2		24
172.16.102.125		172.16.1.25		2		25
172.16.103.100		172.16.1.160		3		0
172.16.103.101		172.16.1.129		3		1
172.16.103.102		172.16.1.130		3		2
172.16.103.103		172.16.1.131		3		3
172.16.103.104		172.16.1.132		3		4
172.16.103.105		172.16.1.133		3		5
172.16.103.106		172.16.1.134		3		6
172.16.103.107		172.16.1.135		3		7
172.16.103.108		172.16.1.136		3		8
172.16.103.109		172.16.1.137		3		9
172.16.103.110		172.16.1.138		3		10
172.16.103.111		172.16.1.139		3		11
172.16.103.112		172.16.1.140		3		12
172.16.103.113		172.16.1.141		3		13
172.16.103.114		172.16.1.142		3		14
172.16.103.115		172.16.1.143		3		15
172.16.103.116		172.16.1.144		3		16
172.16.103.117		172.16.1.145		3		17
172.16.103.118		172.16.1.146		3		18
172.16.103.119		172.16.1.147		3		19
172.16.103.120		172.16.1.148		3		20
172.16.103.121		172.16.1.149		3		21
172.16.103.122		172.16.1.150		3		22
172.16.103.123		172.16.1.151		3		23
172.16.103.124		172.16.1.152		3		24
172.16.103.125		172.16.1.153		3		25
172.16.104.100		172.16.2.32		4		0
172.16.104.101		172.16.2.1		4		1
172.16.104.102		172.16.2.2		4		2
172.16.104.103		172.16.2.3		4		3
172.16.104.104		172.16.2.4		4		4
172.16.104.105		172.16.2.5		4		5
172.16.104.106		172.16.2.6		4		6
172.16.104.107		172.16.2.7		4		7
172.16.104.108		172.16.2.8		4		8
172.16.104.109		172.16.2.9		4		9
172.16.104.110		172.16.2.10		4		10
172.16.104.111		172.16.2.11		4		11
172.16.104.112		172.16.2.12		4		12
172.16.104.113		172.16.2.13		4		13
172.16.104.114		172.16.2.14		4		14
172.16.104.115		172.16.2.15		4		15
172.16.104.116		172.16.2.16		4		16
172.16.104.117		172.16.2.17		4		17
172.16.104.118		172.16.2.18		4		18
172.16.104.119		172.16.2.19		4		19
172.16.104.120		172.16.2.20		4		20
172.16.104.121		172.16.2.21		4		21
172.16.104.122		172.16.2.22		4		22
172.16.104.123		172.16.2.23		4		23
172.16.104.124		172.16.2.24		4		24
172.16.104.125		172.16.2.25		4		25
172.16.105.100		172.16.2.160		5		0
172.16.105.101		172.16.2.129		5		1
172.16.105.102		172.16.2.130		5		2
172.16.105.103		172.16.2.131		5		3
172.16.105.104		172.16.2.132		5		4
172.16.105.105		172.16.2.133		5		5
172.16.105.106		172.16.2.134		5		6
172.16.105.107		172.16.2.135		5		7
172.16.105.108		172.16.2.136		5		8
172.16.105.109		172.16.2.137		5		9
172.16.105.110		172.16.2.138		5		10
172.16.105.111		172.16.2.139		5		11
172.16.105.112		172.16.2.140		5		12
172.16.105.113		172.16.2.141		5		13
172.16.105.114		172.16.2.142		5		14
172.16.105.115		172.16.2.143		5		15
172.16.105.116		172.16.2.144		5		16
172.16.105.117		172.16.2.145		5		17
172.16.105.118		172.16.2.146		5		18
172.16.105.119		172.16.2.147		5		19
172.16.105.120		172.16.2.148		5		20
172.16.105.121		172.16.2.149		5		21
172.16.105.122		172.16.2.150		5		22
172.16.105.123		172.16.2.151		5		23
172.16.105.124		172.16.2.152		5		24
172.16.105.125		172.16.2.153		5		25
172.16.106.100		172.16.3.32		6		0
172.16.106.101		172.16.3.1		6		1
172.16.106.102		172.16.3.2		6		2
172.16.106.103		172.16.3.3		6		3
172.16.106.104		172.16.3.4		6		4
172.16.106.105		172.16.3.5		6		5
172.16.106.106		172.16.3.6		6		6
172.16.106.107		172.16.3.7		6		7
172.16.106.108		172.16.3.8		6		8
172.16.106.109		172.16.3.9		6		9
172.16.106.110		172.16.3.10		6		10
172.16.106.111		172.16.3.11		6		11
172.16.106.112		172.16.3.12		6		12
172.16.106.113		172.16.3.13		6		13
172.16.106.114		172.16.3.14		6		14
172.16.106.115		172.16.3.15		6		15
172.16.106.116		172.16.3.16		6		16
172.16.106.117		172.16.3.17		6		17
172.16.106.118		172.16.3.18		6		18
172.16.106.119		172.16.3.19		6		19
172.16.106.120		172.16.3.20		6		20
172.16.106.121		172.16.3.21		6		21
172.16.106.122		172.16.3.22		6		22
172.16.106.123		172.16.3.23		6		23
172.16.106.124		172.16.3.24		6		24
172.16.106.125		172.16.3.25		6		25
172.16.107.100		172.16.3.160		7		0
172.16.107.101		172.16.3.129		7		1
172.16.107.102		172.16.3.130		7		2
172.16.107.103		172.16.3.131		7		3
172.16.107.104		172.16.3.132		7		4
172.16.107.105		172.16.3.133		7		5
172.16.107.106		172.16.3.134		7		6
172.16.107.107		172.16.3.135		7		7
172.16.107.108		172.16.3.136		7		8
172.16.107.109		172.16.3.137		7		9
172.16.107.110		172.16.3.138		7		10
172.16.107.111		172.16.3.139		7		11
172.16.107.112		172.16.3.140		7		12
172.16.107.113		172.16.3.141		7		13
172.16.107.114		172.16.3.142		7		14
172.16.107.115		172.16.3.143		7		15
172.16.107.116		172.16.3.144		7		16
172.16.107.117		172.16.3.145		7		17
172.16.107.118		172.16.3.146		7		18
172.16.107.119		172.16.3.147		7		19
172.16.107.120		172.16.3.148		7		20
172.16.107.121		172.16.3.149		7		21
172.16.107.122		172.16.3.150		7		22
172.16.107.123		172.16.3.151		7		23
172.16.107.124		172.16.3.152		7		24
172.16.107.125		172.16.3.153		7		25

Printing network-addresses belonging to network B and zone 1 ...
============================================================================
old ip-address		new ip-address		magazine-no	slot-no
172.17.100.100		172.16.8.32		0		0
172.17.100.101		172.16.8.1		0		1
172.17.100.102		172.16.8.2		0		2
172.17.100.103		172.16.8.3		0		3
172.17.100.104		172.16.8.4		0		4
172.17.100.105		172.16.8.5		0		5
172.17.100.106		172.16.8.6		0		6
172.17.100.107		172.16.8.7		0		7
172.17.100.108		172.16.8.8		0		8
172.17.100.109		172.16.8.9		0		9
172.17.100.110		172.16.8.10		0		10
172.17.100.111		172.16.8.11		0		11
172.17.100.112		172.16.8.12		0		12
172.17.100.113		172.16.8.13		0		13
172.17.100.114		172.16.8.14		0		14
172.17.100.115		172.16.8.15		0		15
172.17.100.116		172.16.8.16		0		16
172.17.100.117		172.16.8.17		0		17
172.17.100.118		172.16.8.18		0		18
172.17.100.119		172.16.8.19		0		19
172.17.100.120		172.16.8.20		0		20
172.17.100.121		172.16.8.21		0		21
172.17.100.122		172.16.8.22		0		22
172.17.100.123		172.16.8.23		0		23
172.17.100.124		172.16.8.24		0		24
172.17.100.125		172.16.8.25		0		25
172.17.101.100		172.16.8.160		1		0
172.17.101.101		172.16.8.129		1		1
172.17.101.102		172.16.8.130		1		2
172.17.101.103		172.16.8.131		1		3
172.17.101.104		172.16.8.132		1		4
172.17.101.105		172.16.8.133		1		5
172.17.101.106		172.16.8.134		1		6
172.17.101.107		172.16.8.135		1		7
172.17.101.108		172.16.8.136		1		8
172.17.101.109		172.16.8.137		1		9
172.17.101.110		172.16.8.138		1		10
172.17.101.111		172.16.8.139		1		11
172.17.101.112		172.16.8.140		1		12
172.17.101.113		172.16.8.141		1		13
172.17.101.114		172.16.8.142		1		14
172.17.101.115		172.16.8.143		1		15
172.17.101.116		172.16.8.144		1		16
172.17.101.117		172.16.8.145		1		17
172.17.101.118		172.16.8.146		1		18
172.17.101.119		172.16.8.147		1		19
172.17.101.120		172.16.8.148		1		20
172.17.101.121		172.16.8.149		1		21
172.17.101.122		172.16.8.150		1		22
172.17.101.123		172.16.8.151		1		23
172.17.101.124		172.16.8.152		1		24
172.17.101.125		172.16.8.153		1		25
172.17.102.100		172.16.9.32		2		0
172.17.102.101		172.16.9.1		2		1
172.17.102.102		172.16.9.2		2		2
172.17.102.103		172.16.9.3		2		3
172.17.102.104		172.16.9.4		2		4
172.17.102.105		172.16.9.5		2		5
172.17.102.106		172.16.9.6		2		6
172.17.102.107		172.16.9.7		2		7
172.17.102.108		172.16.9.8		2		8
172.17.102.109		172.16.9.9		2		9
172.17.102.110		172.16.9.10		2		10
172.17.102.111		172.16.9.11		2		11
172.17.102.112		172.16.9.12		2		12
172.17.102.113		172.16.9.13		2		13
172.17.102.114		172.16.9.14		2		14
172.17.102.115		172.16.9.15		2		15
172.17.102.116		172.16.9.16		2		16
172.17.102.117		172.16.9.17		2		17
172.17.102.118		172.16.9.18		2		18
172.17.102.119		172.16.9.19		2		19
172.17.102.120		172.16.9.20		2		20
172.17.102.121		172.16.9.21		2		21
172.17.102.122		172.16.9.22		2		22
172.17.102.123		172.16.9.23		2		23
172.17.102.124		172.16.9.24		2		24
172.17.102.125		172.16.9.25		2		25
172.17.103.100		172.16.9.160		3		0
172.17.103.101		172.16.9.129		3		1
172.17.103.102		172.16.9.130		3		2
172.17.103.103		172.16.9.131		3		3
172.17.103.104		172.16.9.132		3		4
172.17.103.105		172.16.9.133		3		5
172.17.103.106		172.16.9.134		3		6
172.17.103.107		172.16.9.135		3		7
172.17.103.108		172.16.9.136		3		8
172.17.103.109		172.16.9.137		3		9
172.17.103.110		172.16.9.138		3		10
172.17.103.111		172.16.9.139		3		11
172.17.103.112		172.16.9.140		3		12
172.17.103.113		172.16.9.141		3		13
172.17.103.114		172.16.9.142		3		14
172.17.103.115		172.16.9.143		3		15
172.17.103.116		172.16.9.144		3		16
172.17.103.117		172.16.9.145		3		17
172.17.103.118		172.16.9.146		3		18
172.17.103.119		172.16.9.147		3		19
172.17.103.120		172.16.9.148		3		20
172.17.103.121		172.16.9.149		3		21
172.17.103.122		172.16.9.150		3		22
172.17.103.123		172.16.9.151		3		23
172.17.103.124		172.16.9.152		3		24
172.17.103.125		172.16.9.153		3		25
172.17.104.100		172.16.10.32		4		0
172.17.104.101		172.16.10.1		4		1
172.17.104.102		172.16.10.2		4		2
172.17.104.103		172.16.10.3		4		3
172.17.104.104		172.16.10.4		4		4
172.17.104.105		172.16.10.5		4		5
172.17.104.106		172.16.10.6		4		6
172.17.104.107		172.16.10.7		4		7
172.17.104.108		172.16.10.8		4		8
172.17.104.109		172.16.10.9		4		9
172.17.104.110		172.16.10.10		4		10
172.17.104.111		172.16.10.11		4		11
172.17.104.112		172.16.10.12		4		12
172.17.104.113		172.16.10.13		4		13
172.17.104.114		172.16.10.14		4		14
172.17.104.115		172.16.10.15		4		15
172.17.104.116		172.16.10.16		4		16
172.17.104.117		172.16.10.17		4		17
172.17.104.118		172.16.10.18		4		18
172.17.104.119		172.16.10.19		4		19
172.17.104.120		172.16.10.20		4		20
172.17.104.121		172.16.10.21		4		21
172.17.104.122		172.16.10.22		4		22
172.17.104.123		172.16.10.23		4		23
172.17.104.124		172.16.10.24		4		24
172.17.104.125		172.16.10.25		4		25
172.17.105.100		172.16.10.160		5		0
172.17.105.101		172.16.10.129		5		1
172.17.105.102		172.16.10.130		5		2
172.17.105.103		172.16.10.131		5		3
172.17.105.104		172.16.10.132		5		4
172.17.105.105		172.16.10.133		5		5
172.17.105.106		172.16.10.134		5		6
172.17.105.107		172.16.10.135		5		7
172.17.105.108		172.16.10.136		5		8
172.17.105.109		172.16.10.137		5		9
172.17.105.110		172.16.10.138		5		10
172.17.105.111		172.16.10.139		5		11
172.17.105.112		172.16.10.140		5		12
172.17.105.113		172.16.10.141		5		13
172.17.105.114		172.16.10.142		5		14
172.17.105.115		172.16.10.143		5		15
172.17.105.116		172.16.10.144		5		16
172.17.105.117		172.16.10.145		5		17
172.17.105.118		172.16.10.146		5		18
172.17.105.119		172.16.10.147		5		19
172.17.105.120		172.16.10.148		5		20
172.17.105.121		172.16.10.149		5		21
172.17.105.122		172.16.10.150		5		22
172.17.105.123		172.16.10.151		5		23
172.17.105.124		172.16.10.152		5		24
172.17.105.125		172.16.10.153		5		25
172.17.106.100		172.16.11.32		6		0
172.17.106.101		172.16.11.1		6		1
172.17.106.102		172.16.11.2		6		2
172.17.106.103		172.16.11.3		6		3
172.17.106.104		172.16.11.4		6		4
172.17.106.105		172.16.11.5		6		5
172.17.106.106		172.16.11.6		6		6
172.17.106.107		172.16.11.7		6		7
172.17.106.108		172.16.11.8		6		8
172.17.106.109		172.16.11.9		6		9
172.17.106.110		172.16.11.10		6		10
172.17.106.111		172.16.11.11		6		11
172.17.106.112		172.16.11.12		6		12
172.17.106.113		172.16.11.13		6		13
172.17.106.114		172.16.11.14		6		14
172.17.106.115		172.16.11.15		6		15
172.17.106.116		172.16.11.16		6		16
172.17.106.117		172.16.11.17		6		17
172.17.106.118		172.16.11.18		6		18
172.17.106.119		172.16.11.19		6		19
172.17.106.120		172.16.11.20		6		20
172.17.106.121		172.16.11.21		6		21
172.17.106.122		172.16.11.22		6		22
172.17.106.123		172.16.11.23		6		23
172.17.106.124		172.16.11.24		6		24
172.17.106.125		172.16.11.25		6		25
172.17.107.100		172.16.11.160		7		0
172.17.107.101		172.16.11.129		7		1
172.17.107.102		172.16.11.130		7		2
172.17.107.103		172.16.11.131		7		3
172.17.107.104		172.16.11.132		7		4
172.17.107.105		172.16.11.133		7		5
172.17.107.106		172.16.11.134		7		6
172.17.107.107		172.16.11.135		7		7
172.17.107.108		172.16.11.136		7		8
172.17.107.109		172.16.11.137		7		9
172.17.107.110		172.16.11.138		7		10
172.17.107.111		172.16.11.139		7		11
172.17.107.112		172.16.11.140		7		12
172.17.107.113		172.16.11.141		7		13
172.17.107.114		172.16.11.142		7		14
172.17.107.115		172.16.11.143		7		15
172.17.107.116		172.16.11.144		7		16
172.17.107.117		172.16.11.145		7		17
172.17.107.118		172.16.11.146		7		18
172.17.107.119		172.16.11.147		7		19
172.17.107.120		172.16.11.148		7		20
172.17.107.121		172.16.11.149		7		21
172.17.107.122		172.16.11.150		7		22
172.17.107.123		172.16.11.151		7		23
172.17.107.124		172.16.11.152		7		24
172.17.107.125		172.16.11.153		7		25

Printing network-addresses belonging to network A and zone 2 ...
============================================================================
old ip-address		new ip-address		magazine-no	slot-no
172.18.100.100		172.16.16.32		0		0
172.18.100.101		172.16.16.1		0		1
172.18.100.102		172.16.16.2		0		2
172.18.100.103		172.16.16.3		0		3
172.18.100.104		172.16.16.4		0		4
172.18.100.105		172.16.16.5		0		5
172.18.100.106		172.16.16.6		0		6
172.18.100.107		172.16.16.7		0		7
172.18.100.108		172.16.16.8		0		8
172.18.100.109		172.16.16.9		0		9
172.18.100.110		172.16.16.10		0		10
172.18.100.111		172.16.16.11		0		11
172.18.100.112		172.16.16.12		0		12
172.18.100.113		172.16.16.13		0		13
172.18.100.114		172.16.16.14		0		14
172.18.100.115		172.16.16.15		0		15
172.18.100.116		172.16.16.16		0		16
172.18.100.117		172.16.16.17		0		17
172.18.100.118		172.16.16.18		0		18
172.18.100.119		172.16.16.19		0		19
172.18.100.120		172.16.16.20		0		20
172.18.100.121		172.16.16.21		0		21
172.18.100.122		172.16.16.22		0		22
172.18.100.123		172.16.16.23		0		23
172.18.100.124		172.16.16.24		0		24
172.18.100.125		172.16.16.25		0		25
172.18.101.100		172.16.16.160		1		0
172.18.101.101		172.16.16.129		1		1
172.18.101.102		172.16.16.130		1		2
172.18.101.103		172.16.16.131		1		3
172.18.101.104		172.16.16.132		1		4
172.18.101.105		172.16.16.133		1		5
172.18.101.106		172.16.16.134		1		6
172.18.101.107		172.16.16.135		1		7
172.18.101.108		172.16.16.136		1		8
172.18.101.109		172.16.16.137		1		9
172.18.101.110		172.16.16.138		1		10
172.18.101.111		172.16.16.139		1		11
172.18.101.112		172.16.16.140		1		12
172.18.101.113		172.16.16.141		1		13
172.18.101.114		172.16.16.142		1		14
172.18.101.115		172.16.16.143		1		15
172.18.101.116		172.16.16.144		1		16
172.18.101.117		172.16.16.145		1		17
172.18.101.118		172.16.16.146		1		18
172.18.101.119		172.16.16.147		1		19
172.18.101.120		172.16.16.148		1		20
172.18.101.121		172.16.16.149		1		21
172.18.101.122		172.16.16.150		1		22
172.18.101.123		172.16.16.151		1		23
172.18.101.124		172.16.16.152		1		24
172.18.101.125		172.16.16.153		1		25
172.18.102.100		172.16.17.32		2		0
172.18.102.101		172.16.17.1		2		1
172.18.102.102		172.16.17.2		2		2
172.18.102.103		172.16.17.3		2		3
172.18.102.104		172.16.17.4		2		4
172.18.102.105		172.16.17.5		2		5
172.18.102.106		172.16.17.6		2		6
172.18.102.107		172.16.17.7		2		7
172.18.102.108		172.16.17.8		2		8
172.18.102.109		172.16.17.9		2		9
172.18.102.110		172.16.17.10		2		10
172.18.102.111		172.16.17.11		2		11
172.18.102.112		172.16.17.12		2		12
172.18.102.113		172.16.17.13		2		13
172.18.102.114		172.16.17.14		2		14
172.18.102.115		172.16.17.15		2		15
172.18.102.116		172.16.17.16		2		16
172.18.102.117		172.16.17.17		2		17
172.18.102.118		172.16.17.18		2		18
172.18.102.119		172.16.17.19		2		19
172.18.102.120		172.16.17.20		2		20
172.18.102.121		172.16.17.21		2		21
172.18.102.122		172.16.17.22		2		22
172.18.102.123		172.16.17.23		2		23
172.18.102.124		172.16.17.24		2		24
172.18.102.125		172.16.17.25		2		25
172.18.103.100		172.16.17.160		3		0
172.18.103.101		172.16.17.129		3		1
172.18.103.102		172.16.17.130		3		2
172.18.103.103		172.16.17.131		3		3
172.18.103.104		172.16.17.132		3		4
172.18.103.105		172.16.17.133		3		5
172.18.103.106		172.16.17.134		3		6
172.18.103.107		172.16.17.135		3		7
172.18.103.108		172.16.17.136		3		8
172.18.103.109		172.16.17.137		3		9
172.18.103.110		172.16.17.138		3		10
172.18.103.111		172.16.17.139		3		11
172.18.103.112		172.16.17.140		3		12
172.18.103.113		172.16.17.141		3		13
172.18.103.114		172.16.17.142		3		14
172.18.103.115		172.16.17.143		3		15
172.18.103.116		172.16.17.144		3		16
172.18.103.117		172.16.17.145		3		17
172.18.103.118		172.16.17.146		3		18
172.18.103.119		172.16.17.147		3		19
172.18.103.120		172.16.17.148		3		20
172.18.103.121		172.16.17.149		3		21
172.18.103.122		172.16.17.150		3		22
172.18.103.123		172.16.17.151		3		23
172.18.103.124		172.16.17.152		3		24
172.18.103.125		172.16.17.153		3		25
172.18.104.100		172.16.18.32		4		0
172.18.104.101		172.16.18.1		4		1
172.18.104.102		172.16.18.2		4		2
172.18.104.103		172.16.18.3		4		3
172.18.104.104		172.16.18.4		4		4
172.18.104.105		172.16.18.5		4		5
172.18.104.106		172.16.18.6		4		6
172.18.104.107		172.16.18.7		4		7
172.18.104.108		172.16.18.8		4		8
172.18.104.109		172.16.18.9		4		9
172.18.104.110		172.16.18.10		4		10
172.18.104.111		172.16.18.11		4		11
172.18.104.112		172.16.18.12		4		12
172.18.104.113		172.16.18.13		4		13
172.18.104.114		172.16.18.14		4		14
172.18.104.115		172.16.18.15		4		15
172.18.104.116		172.16.18.16		4		16
172.18.104.117		172.16.18.17		4		17
172.18.104.118		172.16.18.18		4		18
172.18.104.119		172.16.18.19		4		19
172.18.104.120		172.16.18.20		4		20
172.18.104.121		172.16.18.21		4		21
172.18.104.122		172.16.18.22		4		22
172.18.104.123		172.16.18.23		4		23
172.18.104.124		172.16.18.24		4		24
172.18.104.125		172.16.18.25		4		25
172.18.105.100		172.16.18.160		5		0
172.18.105.101		172.16.18.129		5		1
172.18.105.102		172.16.18.130		5		2
172.18.105.103		172.16.18.131		5		3
172.18.105.104		172.16.18.132		5		4
172.18.105.105		172.16.18.133		5		5
172.18.105.106		172.16.18.134		5		6
172.18.105.107		172.16.18.135		5		7
172.18.105.108		172.16.18.136		5		8
172.18.105.109		172.16.18.137		5		9
172.18.105.110		172.16.18.138		5		10
172.18.105.111		172.16.18.139		5		11
172.18.105.112		172.16.18.140		5		12
172.18.105.113		172.16.18.141		5		13
172.18.105.114		172.16.18.142		5		14
172.18.105.115		172.16.18.143		5		15
172.18.105.116		172.16.18.144		5		16
172.18.105.117		172.16.18.145		5		17
172.18.105.118		172.16.18.146		5		18
172.18.105.119		172.16.18.147		5		19
172.18.105.120		172.16.18.148		5		20
172.18.105.121		172.16.18.149		5		21
172.18.105.122		172.16.18.150		5		22
172.18.105.123		172.16.18.151		5		23
172.18.105.124		172.16.18.152		5		24
172.18.105.125		172.16.18.153		5		25
172.18.106.100		172.16.19.32		6		0
172.18.106.101		172.16.19.1		6		1
172.18.106.102		172.16.19.2		6		2
172.18.106.103		172.16.19.3		6		3
172.18.106.104		172.16.19.4		6		4
172.18.106.105		172.16.19.5		6		5
172.18.106.106		172.16.19.6		6		6
172.18.106.107		172.16.19.7		6		7
172.18.106.108		172.16.19.8		6		8
172.18.106.109		172.16.19.9		6		9
172.18.106.110		172.16.19.10		6		10
172.18.106.111		172.16.19.11		6		11
172.18.106.112		172.16.19.12		6		12
172.18.106.113		172.16.19.13		6		13
172.18.106.114		172.16.19.14		6		14
172.18.106.115		172.16.19.15		6		15
172.18.106.116		172.16.19.16		6		16
172.18.106.117		172.16.19.17		6		17
172.18.106.118		172.16.19.18		6		18
172.18.106.119		172.16.19.19		6		19
172.18.106.120		172.16.19.20		6		20
172.18.106.121		172.16.19.21		6		21
172.18.106.122		172.16.19.22		6		22
172.18.106.123		172.16.19.23		6		23
172.18.106.124		172.16.19.24		6		24
172.18.106.125		172.16.19.25		6		25
172.18.107.100		172.16.19.160		7		0
172.18.107.101		172.16.19.129		7		1
172.18.107.102		172.16.19.130		7		2
172.18.107.103		172.16.19.131		7		3
172.18.107.104		172.16.19.132		7		4
172.18.107.105		172.16.19.133		7		5
172.18.107.106		172.16.19.134		7		6
172.18.107.107		172.16.19.135		7		7
172.18.107.108		172.16.19.136		7		8
172.18.107.109		172.16.19.137		7		9
172.18.107.110		172.16.19.138		7		10
172.18.107.111		172.16.19.139		7		11
172.18.107.112		172.16.19.140		7		12
172.18.107.113		172.16.19.141		7		13
172.18.107.114		172.16.19.142		7		14
172.18.107.115		172.16.19.143		7		15
172.18.107.116		172.16.19.144		7		16
172.18.107.117		172.16.19.145		7		17
172.18.107.118		172.16.19.146		7		18
172.18.107.119		172.16.19.147		7		19
172.18.107.120		172.16.19.148		7		20
172.18.107.121		172.16.19.149		7		21
172.18.107.122		172.16.19.150		7		22
172.18.107.123		172.16.19.151		7		23
172.18.107.124		172.16.19.152		7		24
172.18.107.125		172.16.19.153		7		25

Printing network-addresses belonging to network B and zone 2 ...
============================================================================
old ip-address		new ip-address		magazine-no	slot-no
172.19.100.100		172.16.24.32		0		0
172.19.100.101		172.16.24.1		0		1
172.19.100.102		172.16.24.2		0		2
172.19.100.103		172.16.24.3		0		3
172.19.100.104		172.16.24.4		0		4
172.19.100.105		172.16.24.5		0		5
172.19.100.106		172.16.24.6		0		6
172.19.100.107		172.16.24.7		0		7
172.19.100.108		172.16.24.8		0		8
172.19.100.109		172.16.24.9		0		9
172.19.100.110		172.16.24.10		0		10
172.19.100.111		172.16.24.11		0		11
172.19.100.112		172.16.24.12		0		12
172.19.100.113		172.16.24.13		0		13
172.19.100.114		172.16.24.14		0		14
172.19.100.115		172.16.24.15		0		15
172.19.100.116		172.16.24.16		0		16
172.19.100.117		172.16.24.17		0		17
172.19.100.118		172.16.24.18		0		18
172.19.100.119		172.16.24.19		0		19
172.19.100.120		172.16.24.20		0		20
172.19.100.121		172.16.24.21		0		21
172.19.100.122		172.16.24.22		0		22
172.19.100.123		172.16.24.23		0		23
172.19.100.124		172.16.24.24		0		24
172.19.100.125		172.16.24.25		0		25
172.19.101.100		172.16.24.160		1		0
172.19.101.101		172.16.24.129		1		1
172.19.101.102		172.16.24.130		1		2
172.19.101.103		172.16.24.131		1		3
172.19.101.104		172.16.24.132		1		4
172.19.101.105		172.16.24.133		1		5
172.19.101.106		172.16.24.134		1		6
172.19.101.107		172.16.24.135		1		7
172.19.101.108		172.16.24.136		1		8
172.19.101.109		172.16.24.137		1		9
172.19.101.110		172.16.24.138		1		10
172.19.101.111		172.16.24.139		1		11
172.19.101.112		172.16.24.140		1		12
172.19.101.113		172.16.24.141		1		13
172.19.101.114		172.16.24.142		1		14
172.19.101.115		172.16.24.143		1		15
172.19.101.116		172.16.24.144		1		16
172.19.101.117		172.16.24.145		1		17
172.19.101.118		172.16.24.146		1		18
172.19.101.119		172.16.24.147		1		19
172.19.101.120		172.16.24.148		1		20
172.19.101.121		172.16.24.149		1		21
172.19.101.122		172.16.24.150		1		22
172.19.101.123		172.16.24.151		1		23
172.19.101.124		172.16.24.152		1		24
172.19.101.125		172.16.24.153		1		25
172.19.102.100		172.16.25.32		2		0
172.19.102.101		172.16.25.1		2		1
172.19.102.102		172.16.25.2		2		2
172.19.102.103		172.16.25.3		2		3
172.19.102.104		172.16.25.4		2		4
172.19.102.105		172.16.25.5		2		5
172.19.102.106		172.16.25.6		2		6
172.19.102.107		172.16.25.7		2		7
172.19.102.108		172.16.25.8		2		8
172.19.102.109		172.16.25.9		2		9
172.19.102.110		172.16.25.10		2		10
172.19.102.111		172.16.25.11		2		11
172.19.102.112		172.16.25.12		2		12
172.19.102.113		172.16.25.13		2		13
172.19.102.114		172.16.25.14		2		14
172.19.102.115		172.16.25.15		2		15
172.19.102.116		172.16.25.16		2		16
172.19.102.117		172.16.25.17		2		17
172.19.102.118		172.16.25.18		2		18
172.19.102.119		172.16.25.19		2		19
172.19.102.120		172.16.25.20		2		20
172.19.102.121		172.16.25.21		2		21
172.19.102.122		172.16.25.22		2		22
172.19.102.123		172.16.25.23		2		23
172.19.102.124		172.16.25.24		2		24
172.19.102.125		172.16.25.25		2		25
172.19.103.100		172.16.25.160		3		0
172.19.103.101		172.16.25.129		3		1
172.19.103.102		172.16.25.130		3		2
172.19.103.103		172.16.25.131		3		3
172.19.103.104		172.16.25.132		3		4
172.19.103.105		172.16.25.133		3		5
172.19.103.106		172.16.25.134		3		6
172.19.103.107		172.16.25.135		3		7
172.19.103.108		172.16.25.136		3		8
172.19.103.109		172.16.25.137		3		9
172.19.103.110		172.16.25.138		3		10
172.19.103.111		172.16.25.139		3		11
172.19.103.112		172.16.25.140		3		12
172.19.103.113		172.16.25.141		3		13
172.19.103.114		172.16.25.142		3		14
172.19.103.115		172.16.25.143		3		15
172.19.103.116		172.16.25.144		3		16
172.19.103.117		172.16.25.145		3		17
172.19.103.118		172.16.25.146		3		18
172.19.103.119		172.16.25.147		3		19
172.19.103.120		172.16.25.148		3		20
172.19.103.121		172.16.25.149		3		21
172.19.103.122		172.16.25.150		3		22
172.19.103.123		172.16.25.151		3		23
172.19.103.124		172.16.25.152		3		24
172.19.103.125		172.16.25.153		3		25
172.19.104.100		172.16.26.32		4		0
172.19.104.101		172.16.26.1		4		1
172.19.104.102		172.16.26.2		4		2
172.19.104.103		172.16.26.3		4		3
172.19.104.104		172.16.26.4		4		4
172.19.104.105		172.16.26.5		4		5
172.19.104.106		172.16.26.6		4		6
172.19.104.107		172.16.26.7		4		7
172.19.104.108		172.16.26.8		4		8
172.19.104.109		172.16.26.9		4		9
172.19.104.110		172.16.26.10		4		10
172.19.104.111		172.16.26.11		4		11
172.19.104.112		172.16.26.12		4		12
172.19.104.113		172.16.26.13		4		13
172.19.104.114		172.16.26.14		4		14
172.19.104.115		172.16.26.15		4		15
172.19.104.116		172.16.26.16		4		16
172.19.104.117		172.16.26.17		4		17
172.19.104.118		172.16.26.18		4		18
172.19.104.119		172.16.26.19		4		19
172.19.104.120		172.16.26.20		4		20
172.19.104.121		172.16.26.21		4		21
172.19.104.122		172.16.26.22		4		22
172.19.104.123		172.16.26.23		4		23
172.19.104.124		172.16.26.24		4		24
172.19.104.125		172.16.26.25		4		25
172.19.105.100		172.16.26.160		5		0
172.19.105.101		172.16.26.129		5		1
172.19.105.102		172.16.26.130		5		2
172.19.105.103		172.16.26.131		5		3
172.19.105.104		172.16.26.132		5		4
172.19.105.105		172.16.26.133		5		5
172.19.105.106		172.16.26.134		5		6
172.19.105.107		172.16.26.135		5		7
172.19.105.108		172.16.26.136		5		8
172.19.105.109		172.16.26.137		5		9
172.19.105.110		172.16.26.138		5		10
172.19.105.111		172.16.26.139		5		11
172.19.105.112		172.16.26.140		5		12
172.19.105.113		172.16.26.141		5		13
172.19.105.114		172.16.26.142		5		14
172.19.105.115		172.16.26.143		5		15
172.19.105.116		172.16.26.144		5		16
172.19.105.117		172.16.26.145		5		17
172.19.105.118		172.16.26.146		5		18
172.19.105.119		172.16.26.147		5		19
172.19.105.120		172.16.26.148		5		20
172.19.105.121		172.16.26.149		5		21
172.19.105.122		172.16.26.150		5		22
172.19.105.123		172.16.26.151		5		23
172.19.105.124		172.16.26.152		5		24
172.19.105.125		172.16.26.153		5		25
172.19.106.100		172.16.27.32		6		0
172.19.106.101		172.16.27.1		6		1
172.19.106.102		172.16.27.2		6		2
172.19.106.103		172.16.27.3		6		3
172.19.106.104		172.16.27.4		6		4
172.19.106.105		172.16.27.5		6		5
172.19.106.106		172.16.27.6		6		6
172.19.106.107		172.16.27.7		6		7
172.19.106.108		172.16.27.8		6		8
172.19.106.109		172.16.27.9		6		9
172.19.106.110		172.16.27.10		6		10
172.19.106.111		172.16.27.11		6		11
172.19.106.112		172.16.27.12		6		12
172.19.106.113		172.16.27.13		6		13
172.19.106.114		172.16.27.14		6		14
172.19.106.115		172.16.27.15		6		15
172.19.106.116		172.16.27.16		6		16
172.19.106.117		172.16.27.17		6		17
172.19.106.118		172.16.27.18		6		18
172.19.106.119		172.16.27.19		6		19
172.19.106.120		172.16.27.20		6		20
172.19.106.121		172.16.27.21		6		21
172.19.106.122		172.16.27.22		6		22
172.19.106.123		172.16.27.23		6		23
172.19.106.124		172.16.27.24		6		24
172.19.106.125		172.16.27.25		6		25
172.19.107.100		172.16.27.160		7		0
172.19.107.101		172.16.27.129		7		1
172.19.107.102		172.16.27.130		7		2
172.19.107.103		172.16.27.131		7		3
172.19.107.104		172.16.27.132		7		4
172.19.107.105		172.16.27.133		7		5
172.19.107.106		172.16.27.134		7		6
172.19.107.107		172.16.27.135		7		7
172.19.107.108		172.16.27.136		7		8
172.19.107.109		172.16.27.137		7		9
172.19.107.110		172.16.27.138		7		10
172.19.107.111		172.16.27.139		7		11
172.19.107.112		172.16.27.140		7		12
172.19.107.113		172.16.27.141		7		13
172.19.107.114		172.16.27.142		7		14
172.19.107.115		172.16.27.143		7		15
172.19.107.116		172.16.27.144		7		16
172.19.107.117		172.16.27.145		7		17
172.19.107.118		172.16.27.146		7		18
172.19.107.119		172.16.27.147		7		19
172.19.107.120		172.16.27.148		7		20
172.19.107.121		172.16.27.149		7		21
172.19.107.122		172.16.27.150		7		22
172.19.107.123		172.16.27.151		7		23
172.19.107.124		172.16.27.152		7		24
172.19.107.125		172.16.27.153		7		25

General
The instructions in this section currently just deal with what must be done on
the tos1/tos2 alpha machines (Linux machines) to get the EAB CW/OS lab
environment to work.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Instructions
To be able to build (run epct) from the tos1/tos2 alpha machines at the EAB
CW/OS lab, the following must be set up:

- Log in to the first IO processor (IO1) with e.g. ssh or telnet.

- If not already done, update and activate the file /opt/telorb/etc/exports
  (Linux OS on IO) or /opt/telorb/etc/dfstab (Solaris OS on IO) as described in
  section IO processor software upgrade (tools).
    (E.g. the export file settings are activated by restarting the NFS server:
       su
       psw
       /etc/rc3.d/S15nfs restart
       exit
    Verify that the exports file settings have been activated:
       /usr/sbin/exportfs)

  Repeat for the other IO processor (IO2).

- Log in to tos1 with e.g. telnet. (Either do tos1 and tos2 simultaneously or
                                    one after the other)

- Enter superuser mode (root):
    su                                        (Enter superuser mode)
    psw                                       (Type password)

- Make it possible for the tos machine to access the new IO processors by adding
  IO specific lines in the /etc/fstab file on the tos machine for the system
  to be added. Below you will find some examples. (Replace toX with the system
  name of the new TelORB system, e.g. to85.)

  For TSP 4.0 Clusterware&OS (TelORB R14pX) and later:
    toXio1:/opt/telorb         /toX/toXio1/telorb            nfs     soft,bg,intr,rw
    toXio2:/opt/telorb         /toX/toXio2/telorb            nfs     soft,bg,intr,rw

  Earlier than TelORB R14:
    #toXio1:/etc		/toX/toXio1/etc			nfs	soft,bg,intr,rw
    #toXio1:/tftpboot		/toX/toXio1/tftpboot		nfs	soft,bg,intr,rw
    toXio1:/opt/telorb		/toX/toXio1/telorb		nfs	soft,bg,intr,rw
    toXio1:/opt/telorb/axe	/toX/toXio1/telorb/axe		nfs	soft,bg,intr,rw
    toXio1:/opt/telorb/dumps	/toX/toXio1/telorb/dumps	nfs	soft,bg,intr,rw

    #toXio2:/etc		/toX/toXio2/etc			nfs	soft,bg,intr,rw
    #toXio2:/tftpboot		/toX/toXio2/tftpboot		nfs	soft,bg,intr,rw
    toXio2:/opt/telorb		/toX/toXio2/telorb		nfs	soft,bg,intr,rw
    toXio2:/opt/telorb/axe	/toX/toXio2/telorb/axe		nfs	soft,bg,intr,rw
    toXio2:/opt/telorb/dumps	/toX/toXio2/telorb/dumps	nfs	soft,bg,intr,rw

- Save the /etc/fstab file.

- Create the following directories (recursively) on the tos machine (as
  superuser):
    mkdir -p /toX/toXio1/telorb/             (Adjust toX to valid TelORB system)
    mkdir -p /toX/toXio2/telorb/             (Adjust toX to valid TelORB system)

- Change owner, group and access permissions of the telorb directory:
    cd /toX/toXio1/                          (Adjust toX to valid TelORB system)
    chown telorb:uab telorb                  (Change owner and group)
    chmod 775 telorb                         (Change access permissions)???

    cd /toX/toXio2/                          (Adjust toX to valid TelORB system)
    chown telorb:uab telorb                  (Change owner and group)
    chmod 775 telorb                         (Change access permissions)???

- Check if your system is already mounted:
    mount | grep toX                         (Adjust toX to valid TelORB system)

- Mount the new IO processor settings one by one or by using the contents of the
  /etc/fstab file (as superuser) (Adjust toX to valid TelORB system):

    For TSP 4.0 Clusterware&OS (TelORB R14pX) and later:
      mount /toX/toXio1/telorb
      mount /toX/toXio2/telorb

    Earlier than TelORB R14:
      mount /toX/toXio1/telorb
      mount /toX/toXio1/telorb/axe
      mount /toX/toXio1/telorb/dumps
      mount /toX/toXio2/telorb
      mount /toX/toXio2/telorb/axe
      mount /toX/toXio2/telorb/dumps

    By using the contents of the /etc/fstab file (will take quite a long time):
      mount -a

- Verify the mounting:
    mount | grep toX                         (Adjust toX to valid TelORB system)

(- If desired, check all mountings (may be very time consuming):
     mount )

- Exit superuser mode:
    exit

- Verify that you can reach the IO processors from tos:
    ls -l /toX/toXio1/telorb/axe/            (Adjust toX to valid TelORB system)
    ls -l /toX/toXio1/telorb/axe/            (Adjust toX to valid TelORB system)

- Create work environment directories (enough to do this for only one of the tos
  machines):
    mkdir /home/dicostest/tosFiles/toX       (Adjust toX to valid TelORB system)
    mkdir /home/dicostest/tosFiles/toX/axe
    mkdir /home/dicostest/tosFiles/toX/ad14       (Adjust ad14 to valid release)
    mkdir /home/dicostest/tosFiles/toX/ad14/epws

- Link loadingGroups and upgrade packages (enough to do this for only one of the
  tos machines)

    cd /home/dicostest/tosFiles/toX/axe
    ln -s /toX/toXio1/telorb/axe/loadingGroup01_1/ loadingGroup01_1
    ln -s /toX/toXio2/telorb/axe/loadingGroup01_2/ loadingGroup01_2
    ln -s /toX/toXio1/telorb/axe/upgradePackages/ upgradePackages

- Create shortcut links from the tos machine to the build environment of the new
  TelORB system (enough to do this for only one of the tos machines):
    cd /home/telorb
    ln -s /home/dicostest/tosFiles/toX toX   (Adjust toX to valid TelORB system)

- Repeat each step above for tos2, if not already done.
  (The added lines in the file /etc/fstab may be copied to the /etc/fstab file
  on tos2.)


Hints

The following applies when e.g. the TelORB system has been kickstarted.

If it is not possible to build on tos1/tos2, e.g. if the following printouts are
received:

  "epct: copying load files to /home/dicostest/tosFiles/to28/axe/loadingGroup01_1/codeArchive
  cp: /home/dicostest/tosFiles/to28/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R1N.i486: Permission denied
  epct: WARNING, cannot create /home/dicostest/tosFiles/to28/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R1N.i486
  cp: /home/dicostest/tosFiles/to28/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/ProcessSupport.LM_AXG425.Code.R1N01.i486: Permission denied"

  and/or if the following printout is received when checking the contents of
  the /toX/toXio1/ directory:

  cd /toX/toXio1/                            (Adjust toX to valid TelORB system)
  ls -l
  "ls: telorb: Permission denied
  total 0"

check the exports files on the IO processors are correct (only for the EAB CW/OS
lab) and that NFS is running on the IO processors.
If NFS is not running, start NFS on the IO processors as follows:
R14p13 and higher: Stop and start services.
Lower releases: Run the S15 start script.

If NFS is running, try to unmount and mount on the tos machine as follows:
  mount | grep toX                           (Check)
  su                                         (Enter superuser mode)
  psw                                        (Type password)
  umount /toX/toXio1/telorb                  (Unmount )
  mount | grep toX                           (Adjust toX to valid TelORB system)
  mount /toX/toXio1/telorb                   (Adjust toX to valid TelORB system)
  exit
  mount | grep toX                           (Adjust toX to valid TelORB system)

If it still does not work, unmount and repeat the tos procedure above.

-  -  -  -  -  -  -  -  -  -  -  -

The file /etc/fstab on tos1/tos2 is executed at tos1/tos2 start up and performs
the mounting.
The file /etc/mtab on tos1/tos2 shows current mounting status, i.e. what is
shown when entering the command mount.

If mounting fails and returns e.g. "Permission denied" do as follows on each IO
processor:
  Note: For Linux OS, the file /etc/exports is used instead of dfstab!

  more /etc/dfs/dfstab   (This file is updated when executing telorb.conf during
                          installation of a new IO tools package on an IO
                          processor)
    Should look something like (at the EAB CW/OS lab):
share -F nfs -o rw=@134.138.63:@134.138.64:@134.138.187 /opt/telorb/
share -F nfs -o rw=@134.138.63:@134.138.64:@134.138.187 /opt/telorb/axe/
share -F nfs -o rw=@134.138.63:@134.138.64:@134.138.187 /opt/telorb/dumps
share -F nfs -o rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se /tftpboot
share -F nfs -o rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se /etc

Check what IO settings that are active by reading the file /etc/dfs/sharetab or
by entering the command exportfs.
This file should look something like:
/tftpboot       -       nfs     rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se     
/etc    -       nfs     rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se     
/opt/telorb     -       nfs     rw=@134.138.63:@134.138.64:@134.138.187 
/opt/telorb/axe -       nfs     rw=@134.138.63:@134.138.64:@134.138.187 
/opt/telorb/dumps       -       nfs     rw=@134.138.63:@134.138.64:@134.138.187 

If one or several lines differ between the dfstab and sharetab files, either
reboot the IO processor to activate what is in dfstab or run the differing lines
in dfstab manually (must be superuser). This will update the file
/etc/dfs/sharetab.
To see the contents of the file /etc/dfs/sharetab, either read the file or enter
the command exportfs.

Check permissions of directory /opt/telorb/ on the IO processors:
  cd /opt/
  ls -l
  The telorb directory should have the following permissions:
  drwxr-xr-x  12 telorb   telorb       512 Jun  5 14:35 telorb/  (or drwxrwxrwx)
  If not, enter the following:
  chmod 755 telorb                                         (or chmod 777 telorb)

Now it should be possible to mount on tos1/tos2, see above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

For TelORB release R14 the following instructions may be valid (not decided yet)
For TelORB release R14, new settings for the file system mounting is valid
(use the instructions above to replace the following):

  Replace
    toXio1:/opt/telorb/axe	/toX/toXio1/telorb/axe		nfs	soft,bg,intr,rw
  with
    toXio1:/opt/telorb/axe/loadingGroup01_1 on /toX/toXio1/telorb/axe/loadingGroup01_1 type nfs (rw,soft,bg,intr,addr=134.138.187.44)
    toXio1:/opt/telorb/axe/upgradePackages on /toX/toXio1/telorb/axe/upgradePackages type nfs (rw,soft,bg,intr,addr=134.138.187.44)

  and replace
    toXio2:/opt/telorb/axe	/toX/toXio2/telorb/axe		nfs	soft,bg,intr,rw
  with
    toXio2:/opt/telorb/axe/loadingGroup01_2 on /toX/toXio2/telorb/axe/loadingGroup01_2 type nfs (rw,soft,bg,intr,addr=134.138.187.45)

Also consider the replaced settings when mounting.

In the instructions below regarding changes on the IO processors, the following
is valid:
- Instead of using the unshare and share commands, it is better to edit the
  file /etc/dfs/dfstab to make the changes permanent (in case of an IO processor
  reboot):
    more /etc/dfs/sharetab
    Edit the file /etc/dfs/dfstab.
    ./S15nfs.server stop
    ./S15nfs.server start
    more /etc/dfs/sharetab                (Check that the changes are activated)

On IO processor 1:
  su
  share   (Gives the following printout)
    -               /opt/telorb   rw   ""
    -               /opt/telorb/axe   rw   ""
    -               /opt/telorb/dumps   rw   ""
    -               /tftpboot   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /etc   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""

  unshare /opt/telorb/axe
  share   (Gives the following printout)
    -               /opt/telorb   rw   ""
    -               /opt/telorb/dumps   rw   ""
    -               /tftpboot   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /etc   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""

  share /opt/telorb/axe/loadingGroup01_1
  share /opt/telorb/axe/upgradePackages
  share   (Gives the following printout)
    -               /opt/telorb   rw   ""
    -               /opt/telorb/dumps   rw   ""
    -               /tftpboot   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /etc   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /opt/telorb/axe/loadingGroup01_1   rw   ""
    -               /opt/telorb/axe/upgradePackages   rw   ""
  exit


On IO processor 2:
  su
  share   (Gives the following printout)
    -               /opt/telorb   rw   ""
    -               /opt/telorb/axe   rw   ""
    -               /opt/telorb/dumps   rw   ""
    -               /tftpboot   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /etc   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /export/install   ro,anon=0   ""
  unshare /opt/telorb/axe
  share   (Gives the following printout)
    -               /opt/telorb   rw   ""
    -               /opt/telorb/dumps   rw   ""
    -               /tftpboot   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /etc   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /export/install   ro,anon=0   ""

  share /opt/telorb/axe/loadingGroup01_2
  share   (Gives the following printout)
    -               /opt/telorb   rw   ""
    -               /opt/telorb/dumps   rw   ""
    -               /tftpboot   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /etc   rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se   ""
    -               /export/install   ro,anon=0   ""
    -               /opt/telorb/axe/loadingGroup01_2   rw   ""
  exit

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
It is also possible to mount a part of the fstab file (or other paths), e.g.
  mount /toX/toXio1/telorb/axe                                      (In su mode)
and to unmount a part of the fstab file (or other paths), e.g.
  umount /toX/toXio1/telorb/axe                                     (In su mode)

It is not possible to unmount e.g. /toX/toXio1/telorb/axe if
/toX/toXio1/telorb/axe/loadingGroup01_1 is still mounted. The printout
"umount: /toX/toXio1/telorb/axe: device is busy" is probably received.
In this case, unmount /toX/toXio1/telorb/axe/loadingGroup01_1 and then
/toX/toXio1/telorb/axe, i.e.
  umount /toX/toXio1/telorb/axe/loadingGroup01_1                    (In su mode)
  umount /toX/toXio1/telorb/axe                                     (In su mode)

To make it possible to mount like described above, the file /etc/dfs/dfstab on
both IO processors should look as follows:

  #       Place share(1M) commands here for automatic execution
  #       on entering init state 3.
  #
  #       Issue the command '/etc/init.d/nfs.server start' to run the NFS
  #       daemon processes and the share commands, after adding the very
  #       first entry to this file.
  #
  #       share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]
  #       .e.g,
  #       share  -F nfs  -o rw=engineering  -d "home dirs"  /export/home2

  share -F nfs -o rw  /opt/telorb
  share -F nfs -o rw  /opt/telorb/axe
  share -F nfs -o rw  /opt/telorb/dumps
  share -F nfs -o rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se /tftpboot
  share -F nfs -o rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se /etc

• General
• Penta CW/OS project homepage
• Initial installation
• Build system
• Start LoadViewer
• Start STS (processor consoles)
• Start TelORB Manager
• Delivery server ulinpc49
• Information points of interest & IO and sync info
• IO upgrade
• Temporary fix for reducing long backup times
• Incorrect time in the system?
• Get Linux version
• Auto target tester
• Log in to processor
• Check which cluster control processor that is CM master and OpState/LoaderState
• Processor mapping: index <--> Processor_name on Dicos processors
• Change syslog (or applog) level
• Set up VIP for IPv4/IPv6 and generate traffic
• "RPM processes" running on IOs
• "Heartbeat controlled" processes
• Get emacs and equivalent to work in e.g. su mode
• Mount EAB CW/OS lab environment on IOs
• Copy all epct files from IO2 to IO1
• Copy the "pingall" script + other scripts
• Interpret Dicos error dumps on IO processor
• Interpret Linux error dumps on IO processor
• Location of epct template files
• Location of crash collector files
• Start a full sync
• Modify the Site Database file dbfile.xml using the sitedbclient
• Modify the Site Database file dbfile.xml using e.g. emacs
• Prevent TSP to start on IO
• Avoid IO synching at zone reload
• Connect a serial terminal using utmp05
• Shrink DRBD partition
• Replacing processor
• Disk Database (DDB)
• NetRed information
• Outdated VIP information
• Hints
• Andreas Johansson's tips and trix

(Updated: 2004-06-11)

Highlights of TSP 5.0:
- IO processors are included in the TSP cluster.
- High Availablility File System (with DRBD) is introduced.

Highlights of TSP 5.1:
- IO processors are excluded from the TSP cluster.
  (DRBD synchronization between the IOs will take longer time after an initial
  installation and after a replacement of an IO processor, then it will do in
  any other case. The concepts "full sync" and "quick sync" are no longer used.)
- FS processors are not included in the TSP system at all.
- Disk Database processors are introduced and included in the TSP cluster.
- Application Trace is introduced.
- Application Trace is introduced.
- NSP 5.0 hardware is introduced.
  (For NSP 5.0 HW an external link is added between the two IOs (and also File
  Server pairs if there are any). It is a 1000 BaseT/TX link and is primarily
  intended for speeding up the synchronization process at DRBD synchronization.)

(Updated: 2005-04-20 for TSP 5.1 LSV12)

TSP 5.0: Initial installation of CW/OS at the EAB CW/OS lab
-----------------------------------------------------------
This installation instruction covers the cases when installing from a DVD or
from an installation server.

The parameter values used in these instructions are valid for most of the
TSP systems in the EAB CW/OS lab, using TSP 5.1 LSV512.

DNS and NTP servers which may be used at the EAB CW/OS lab: 134.138.201.17
and/or 134.138.226.13.

Preferably, perform the installation from a workstation in the lab, since some
of the instructions below require manual hardware intervention, i.e. it is
good to be close to the system cabinets.

Installing from DVD or installation server (preparations)
- If the system to be installed is up and running, it is a good idea to
  backup some of the files for e.g. reference reasons. Copy the files
  to a destination outside the IO processors.
  Example of files which may be backed up:
  o /opt/telorb/axe/adm/etc/dbfile.xml   -or-   /opt/mirror/adm/etc/dbfile.xml
  o /opt/telorb/axe/adm/etc/dhcpd.conf   -or-   /opt/mirror/adm/etc/dhcpd.conf
  o /var/opt/tsp/epct/E00NodeType.epct     (or equivalent)
  o /var/opt/tsp/epct/E10cwos_initial.epct (or equivalent)
  o /var/opt/tsp/epct/E10Name.epct         (or equivalent)
  o /var/opt/tsp/epct/TSPRefApp.epct       (or equivalent)
  o Any other files of interest

    E.g.
      scp -r telorb@toXio2:/var/opt/tsp/epct/ .  (Copy all epct files in one go.
                                                   An epct directory will be
                                                   created)
      scp telorb@toXio2:/opt/telorb/axe/adm/etc/dbfile.xml .   (Copy the SiteDb
                                                                file)
      scp telorb@toXio2:/opt/telorb/axe/adm/etc/dhcpd.conf .   (Copy the DHCPD
                                                                file)

- If the system to install TSP 5 in uses NSP 4.0 hardware with Flash disks, you
  have to change the BIOS value for "PCI IDE" in all TelORB processors as
  described below.
  If this step is not performed, the probing of the TelORB processors will not
  succeed in one of the later installation steps. This is due to that the
  processors will be regarded as if they are equipped with hard disks.
  Do as follows:
  - Connect a serial terminal to the processor and open an xterm window.
  - Enter the BIOS of one of the processors (this procedure have to be performed
    on all processors).
  - In the BIOS menu, go to "Integrated Peripherals" => On-Chip Primary.
  - Change the value for "PCI IDE" to "Disable".
     ("Enable" should be used for TSP 4 and "Disable" should be used for TSP 5.)

Installing from installation server
- If an installation server will be used, instead of using the DVD drive
  on IO2, the installation server must be installed with the valid release.
  At the EAB CW/OS lab, the Kickstart server ulinpc52 (134.138.184.175) can
  serve as an installation server.
    - Log in to the installation server, e.g. ulinpc52:
        ssh telorb@ulinpc52
        telorb
        Password: tsP4ever
    - Install the installation server. (This is not yet described in these
      guidelines. Ask uabkrni for installation details.)

Installing from DVD or installation server
- Physically, connect a serial terminal to IO processor 2 and then connect to
  IO2 by using minicom (via e.g. utmp05: ssh telorb@utmp05,
  minicom <number_of_port>)
  In the minicom window, type Ctrl-a z to enter the Minicom configuration menu
  and then adjust the following minicom settings:
  o Terminal settings (T) -> Backspace key sends (B) to "DEL" -> Enter.
  o lineWrap on/off (W) to "Linewrap ON" -> Enter (or wait).
  (o cOnfigure Minicom (O) -> Screen and Keyboard -> Enter -> Macros
     enabled (N) to "No" -> Enter.)
  (For further information about how to use minicom, see
   Connect to remote host using "minicom".)

- Physically, connect a serial terminal to IO processor 1 and then connect to
  IO1 by using minicom (via e.g. utmp05: ssh telorb@utmp05,
  minicom <number_of_port>)
  (Alternatively, use the same serial terminal as was used for IO processor 2.
   In this case, the minicom settings are already performed.)
  In the minicom window, make the same adjustments for the minicom settings as
  was made for IO2.

Installing from DVD
- Change the BIOS settings for IO processor 1 (by using minicom, connected
  above), so that it will boot from the internal network, as follows (values
  valid for NSP 4.1 HW) (For NSP 4.0 HW, use the same values as for installing
  from installation server below, i.e. "LAN 2-1"):
    - Press the reset button on IO processor 1 and then, immediately, hit Del
      (and/or Backspace) repeatedly on the keyboard, with the cursor in the
      valid minicom window. This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "Boot".
      o In "Boot Settings", select "Boot Device Priority" and press Enter.
      o In "Boot Device Priority", select "1st Boot Device" (default) and press
        Enter. A list of available boot options is displayed.
      o Select "IBA FE Slot 0040 v" and press Enter. (NSP5.0: IBA GE Slot
                                                              0319 v1219)
      o Select "2nd Boot Device" and press Enter.
        A list of available boot options is displayed.
      o Select "IBA FE Slot 0038 v" and press Enter. (NSP5.0: IBA GE Slot
                                                              0318 v1219)
      o Press Esc.
      o Select "Exit".
      o In "Exit Options", select "Save Changes and Exit" (default) and press
        Enter.
      o In the opened box "Save configuration changes and exit setup?", select
        "OK", i.e. just press Enter.

      (IO1 will start to repeatedly perform DHCP handling.)

Installing from installation server
- Change the BIOS settings for IO processor 1 (by using minicom, connected
  above), so that it will boot from the internal network, as follows (values
  valid for NSP 4.0 HW):
    - Press the reset button on IO processor 1 and then, immediately, hit Del
      (and/or Backspace) repeatedly on the keyboard, with the cursor in the
      valid minicom window. This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "BIOS FEATURES SETUP" (Virus Protection, Boot Sequence...).
      o In "BIOS FEATURES SETUP", select "Boot From LAN First".
      o In "Boot From LAN First", select "LAN 2-1" (+/-).
      o Press Esc.
      o Select "SAVE & EXIT SETUP" ("Save Data to CMOS & Exit SETUP")
         and press Enter.
      o In "Exit Options", select "Save Changes and Exit" (default) and press
        Enter.
      o In the opened box "SAVE to CMOS and EXIT (Y/N)?", select "y" and press
        Enter.

      (IO1 will start to load, since it is connected to the installation
       server.)

Installing from DVD or installation server
- Verify that all File Servers will also boot from the internal network by
  checking the BIOS value for this on the valid processors.
  See above for valid values for NSP 4.0/NSP 4.1 HW.
  If this is not the case, reconfigure the BIOS setup for all non-correct File
  Servers to boot from the internal network, as described for IO1 above.

- If there are processors in the system which should not be part of the
  installation, physically disconnect these. (No longer necessary?)

(- This step should normally not be followed, since you should
   log in externally to IO2's external IP address later on in these
   instructions:
   Physically, connect the Kickstart Server (e.g. ulinpc52) to the lowest
   connector on the front panel of IO processor 2 (eth2, 100BaseTx0).
   Temorarily disconnect any other cable connected to this connector.
   (The Kickstart Server will only be used as a VNC server).)

Installing from DVD
- Insert the installation DVD into the DVD drive on IO2.

Installing from installation server
- Physically, connect the installed installation server to the 100BaseTx
  port on any of the SCBs.
  At the EAB CW/OS lab, the Kickstart server, ulinpc52
  (134.138.184.175) can serve as an installation server.

- Log in to the installation server, e.g. ulinpc52:
    ssh telorb@ulinpc52
    telorb
    psw

- Verify that the DHCP service is running on the installation server (as
  root):
    su
    psw
    /etc/init.d/dhcpd status
    If dhcpd is stopped (unused):
      /etc/init.d/dhcpd start

Installing from DVD
- Change the BIOS settings for IO processor 2 (by using minicom, connected
  above), so that it will boot from DVD, as follows (values valid for NSP
  4.1 HW) (for NSP 4.0 HW use Boot Sequence = SCSI,C,A):
    - Press the reset button on IO processor 2 and then, immediately, hit Del
      (and/or Backspace) repeatedly on the keyboard, with the cursor in the
      valid minicom window. This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "Boot".
      o In "Boot Settings", select "Boot Device Priority" and press Enter.
      o In "Boot Device Priority", select "1st Boot Device" (default) and press
        Enter. A list of available boot options is displayed.
      o Select "PM-MATSHITADVD-ROM" or equivalent and press Enter.
                                                       (NSP5.0: PM-TEAC DV-W58G)
      o Press Esc.
      o Select "Exit".
      o In "Exit Options", select "Save Changes and Exit" (default) and press
        Enter.
      o In the opened box "Save configuration changes and exit setup?", select
        "OK", i.e. just press Enter.

Installing from installation server
- Change the BIOS settings for IO processor 2 (by using minicom, connected
  above), so that it will boot from the internal network, as follows (values
  valid for NSP 4.0 HW):
    - Press the reset button on IO processor 2 and then, immediately, hit Del
      (and/or Backspace) repeatedly on the keyboard, with the cursor in the
      valid minicom window. This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "BIOS FEATURES SETUP" (Virus Protection, Boot Sequence...).
      o In "BIOS FEATURES SETUP", select "Boot From LAN First".
      o In "Boot From LAN First", select "LAN 2-1" (+/-).
      o Press Esc.
      o Select "SAVE & EXIT SETUP" ("Save Data to CMOS & Exit SETUP")
         and press Enter.
      o In "Exit Options", select "Save Changes and Exit" (default) and press
        Enter.
      o In the opened box "SAVE to CMOS and EXIT (Y/N)?", select "y" and press
        Enter.

- Wait until the OS (linux) has loaded, and until the Linuxrc program has
  started printing messages to the serial terminal (look for e.g. "VNC viewer").

- Stop the DHCP server on the installation server (still as root):
    /etc/init.d/dhcpd stop

Installing from DVD
- On IO processor 2: Wait until the OS (Linux) has loaded, the Linuxrc program
  has started and the first dialog message has been printed on the serial
  terminal.
  
- The following questions and instructions will be displayed on the serial
  terminal connected to IO2:

    "Automatic configuration via DHCP?"
      Answer No, i.e. press Enter.

    "Enter your IP address."
      Enter IO2's IP address on external network A
        (e.g. 134.138.187.55 for to14io2) (e.g. 134.138.187.45 for to11io2)
        (e.g. 134.138.187.57 for to15io2) (e.g. 134.138.187.90 for to20io2)
      and press Enter.
      (Alternatively, use the default 192.168.11.16, i.e. just press Enter.)

    "Enter your netmask. For a normal class C network, this is
                      usually 255.255.255.0."
      Enter the netmask for external network A (e.g. 255.255.248.0 for to14,
      to11, to15 and to20) and press Enter.
      (Alternatively, use the default 255.255.255.0, i.e. just press Enter.)

    "If you need a gateway to reach the server, enter the IP
     address of the gateway. If you do not need a gateway, enter
                      your own IP address."
      Enter the default gateway for external network A (e.g. 134.138.184.1 for
      to14, to11, to15 and to20) and press Enter.
      (Alternatively, use the default 192.168.11.16, i.e. just press Enter.)

    "Enter the IP address of your name server. If you do not use
                      a name server, press ESC."
      A name server is not needed, so just press ESC.

Installing from DVD or installation server
- Wait for the VNC server to start, i.e. until you see the following printouts:
    "starting VNC server...", "Xlib:  extension..."
    Note the IP address and display number printed on the serial terminal
    (e.g. "You can connect to 134.138.187.55, display :1 now with vncviewer"
             -and/or-
          "Or use a Java capable browser on  http://134.138.187.55:5801/").
    (Another example: 192.168.11.16 and display :1)

- If not already done, open a new xterm shell.
  At the EAB CW/OS lab, it is possible to use the lab workstations as VNC
  servers, so in this case, you can skip directly to the next step (i.e. after
  you have opened a new xterm shell).
  Otherwise, log in to a workstation hosting a VNC server, e.g. tos1 or the
  Kickstart server (ulinpc52, 134.138.184.175) ((or e.g. uabbjod's ulinpc132))
  (When installing from an installation server, you may use the same Kickstart
  server window as previously opened).
  E.g.:
    ssh telorb@tos1  -or-  ssh telorb@ulinpc52
    Password: tsP4ever

      (The Kickstart Server will be used as a VNC server, to run the
       VNC viewer on.)

- In the newly opened xterm shell, start the VNC viewer (as telorb):
    vncviewer 134.138.187.55:1 (for to14)  (or 192.168.11.16:1) (Use the IP
                                                             address and display
                                                             number as indicated
                                                             above)
                (vncviewer 134.138.187.45:1  -or-  vncviewer to11io2:1 for to11)
    (Installing from installation server: vncviewer 192.168.11.146:1)

    -or-

    vncviewer toXioY:1                     (Adjust toXioY to valid IO processor)

                      (If the reply is "X11 connection rejected because of wrong
                       authentication", enter the following command:
                         export DISPLAY=134.138.186.45:0.0   (Adjust IP address
                                                              to e.g. your WS)
    Password: <Enter the VNC authentication password> tel123orb

  If you want to monitor the installation progress from yet another workstation,
  just enter the same vncviewer command as entered above from that workstation.

- The VNC-viewer will start and the "Start Installation ?" dialog box will
  appear.
  Verify that the correct product number and revision are displayed in the
  dialog box, as well as the correct hardware platform (e.g. GEM for NSP based
  systems).
  If so, click Continue.
  If not, click "Cancel" to abort the installation.

- Wait for the base software to be installed.
  During the installation of the base software, when the installation has
  reached the point "Perform Installation" / "Basic Installation" / "Install TSP
  runtime files", verify that the correct runtime file is being used by checking
  the "Installing runtime (1of1):". Example of a runtime file:
  "TelORB-R15-LSV510-Runtime.tar.gz".
  Note that the "Install TSP runtime files" operation can take up to 15 minutes
  to execute.

  When this step is completed, the "Select Node Type Template" panel appears.

- Physically remove the DVD from the DVD drive.
  Since the DVD will no longer be used during the installation, it is now safe
  to physically remove it from the DVD drive.

- In the "Select Node Type Template" panel:
    Select the valid node template file which suits your hardware and initial
    software configuration.
     (E.g. select
      TelORB-R15-LSV509C-Runtime/config/epct/NSP4.x_Maxi_CwosMixed.epct.template
      for to11)
    (If you want to change the epct file to suit your system, see hint 4 below.)
    (Also note that all processors must hardwarewise be located in the
    cabinet(s) as specified in the epct file for the probing to succeed.)
    Click Accept.

- The TSP5 Configuration Wizard starts and shows the following text:
    "Welcome to the TSP5 configuration wizard."
    If the opened wizard window is not fully viewable inside the VNC window,
    just move it up a bit.
    Click Next.

- In the "System Timezone" panel:
    Select the correct time zone for the system's local time (e.g.
    Europe/Stockholm). (Double click to open the folders.)
    Click Next.

- In the "Java Heap Settings" panel:
    The default values are normally OK, i.e. Heap (MiB): 30,
                                             Capsule Heap (MiB): 128,
                                             Permanent Heap (MiB): 16.
    Modify, if necessary.
    Click Next.

- In the "Network Time Protocol Configuration" panel:
    Enter the IP address(es) of the external time server(s) (NTP),
    separated by space (e.g. 134.138.201.17 and/or 134.138.226.13, or leave it
    empty if no external NTP server(s) should be used.)
    Note: At least one NTP server must be provided on GEM/NSP based systems,
          since these lack a battery backup for the hardware clocks.
    (When installing from installation server ulinpc52, use ulinpc52's IP
    address, i.e. 134.138.184.175. This address should be changed when the
    installation is finished in SiteDataBase file or via TelORB Manager.)
    Normally, two to three addresses should be provided in order to ensure
    sufficient redundancy. Multicast addresses cannot be used.
    Click Next.

- In the "Domain Name System Configuration" panel:
    Enter the "Internal domain name" for the system. It is recommended that this
    field is either left empty, or a unique domain name for the system is
    entered.
    If leaving the field empty, the default value "tspinternal" will be used.
    Otherwise, any name will do.
    Enter the IP address(es) of the "External name servers" (DNS),
    separated by space (e.g. 134.138.201.17 and/or 134.138.226.13, or leave it
    empty if no external DNS server(s) should be used.)
    Normally, two to three addresses should be provided in order to ensure
    sufficient redundancy. Multicast addresses cannot be used.
    Click Next.

- In the "Zone name" panel:
    Enter the name of the zone (e.g. to14).
    Allowed characters are A-Z, a-z, 0-9 and underscore (_).
    Click Next.

- In the "Local VIP addresses" panel:
    Enter the "External VIP address" (e.g. 172.30.14.14 (previously
    134.138.71.14) for to14) (e.g. 172.30.14.11 for to11) (e.g. 134.138.71.15
    for to15) (e.g. 172.30.14.20 for to20).
    Enter the "Internal VIP address" (Accept the default address
    192.168.63.100 (previously 192.168.100.64) or enter a different internal
    VIP address).
    Click Next.

- OLD INFO FOR LSV12 AND EARLIER! Will soon be removed!
    In the "OSPF (for IPv4) Configuration" panel:
    Modify the OSPF Configuration as needed (or keep the default settings,
    i.e. Area ID: 0, Hello Interval: 10 and Router Dead Interval: 40).
    Normally, only the Area ID needs to be modified, depending on the system's
    specific router configuration.
    (Area ID for to14, to11 and to20: 10.0.0.0 => Corresponds to VIP address
     172.30.14.nn, where nn in this case is 14 for to14 and 11 for to11)
    (Area ID for to15: 0.0.0.0 => Corresponds to VIP address 134.138.71.nn,
     where nn in this case is 15 for to15)
    (172.30.14.nn addresses are used for the Cisco VIP routers in the lab and
     134.138.71.nn addresses are used for the old Cajun VIP routers.)
    Click Next.

- OLD INFO FOR LSV12 AND EARLIER! Will soon be removed!
    In the "OSPF for IPv6 Configuration" panel:
    Modify the OSPF Configuration as needed (or keep the default settings,
    i.e. Area ID: 0, Hello Interval: 10 and Router Dead Interval: 40).
    (Area ID for to14: 10.0.0.0)
    (Area ID for to11: 10.10.10.10)
    (Area ID for to15: 0.0.0.0)
    (Area ID for to20: 10.10.10.10)
    Click Next.

- In the "Network Redundancy" panel:
    When asked "Do you want Network Redundancy (NetRed)?":
    Select Yes or No.
    Click Next.

- OLD INFO FOR LSV12 AND EARLIER! Will soon be removed!
    In the "Network Configuration" panel:
    Configure the internal and external networks for the IOs.
    (To copy and paste in the wizard, use Ctrl-c for copy and Ctrl-v for paste.)

                     Address            Prefix Length
                     -------            -------------
    Internal Net A:  172.16.0.0         /21    (Already filled in)
    Internal Net B:  172.16.8.0         /21    (Already filled in)
    Internal Net C:  172.16.32.0        /21    (Already filled in)

    External Net A:  134.138.184.0      /21    (May already be filled in)
     Gateway:        134.138.184.1             (May already be filled in)
     IO1:            134.138.187.54            (Must be filled in)
                                               (Example for to14io1)
                                                 (to11: 134.138.187.44)
                                                 (to15io1: 134.138.187.56)
                                                 (to20io1: 134.138.187.89)
     IO2:            134.138.187.55            (Already filled in)
                                               (Example for to14io2)
                                                 (to11io2: 134.138.187.45)
                                                 (to15io2: 134.138.187.57)
                                                 (to20io2: 134.138.187.90)

    External Net B:  192.11.0.0         /24    (Fill in, if NSP5.0 HW is used)
     Gateway:        192.11.0.1                (Fill in, if NSP5.0 HW is used)
     IO1:            192.11.0.1                (Fill in, if NSP5.0 HW is used)
     IO2:            192.11.0.2                (Fill in, if NSP5.0 HW is used)

    Note that the "Prefix Length" value (number of bits in the netmask) cannot
    be changed, it must always be set to 21.

    (External Net B (eth3) should be filled in if NSP5.0 HW is being used.
     This is because an extra cable is connected between IO1 (eth3) and IO2
     (eth3), to speed up the DRBD synching time between the IO processor disks.
     This is why this synchronization network is defined.)

-  In the "Network Configuration" panel:
    Configure the internal and external networks for the IOs.
    (To copy and paste in the wizard, use Ctrl-c to copy and Ctrl-v to paste.)

                                Address         Prefix Length
                                -------         -------------
    Internal Network 0 (IN-0):  172.16.8.0      /21   (Already filled in)
    Internal Network 1 (IN-1):  172.16.0.0      /21   (Already filled in)
    Internal Network 2 (IN-2):  172.16.32.0     /21   (Already filled in)

    External Network 0 (EN-0):  134.138.184.0   /21   (May already be filled in)
      Gateway:       134.138.184.1                    (Already be filled in)
      IO1:           134.138.187.54                   (Must be filled in)
                                                      (Example for to14io1)
                                                       (to11: 134.138.187.44)
                                                       (to15io1: 134.138.187.56)
                                                       (to20io1: 134.138.187.89)
      IO2:           134.138.187.55                   (Already filled in)
                                                      (Example for to14io2)
                                                       (to11io2: 134.138.187.45)
                                                       (to15io2: 134.138.187.57)
                                                       (to20io2: 134.138.187.90)

    External Network 1 (EN-1):  192.11.0.0      /24   (Fill in, if NSP5.0 HW
                                                       is used)
      Gateway:       192.11.0.1                       (Fill in, if NSP5.0 HW
                                                       is used)
      IO1:           192.11.0.1                       (Fill in, if NSP5.0 HW
                                                       is used)
      IO2:           192.11.0.2                       (Fill in, if NSP5.0 HW
                                                       is used)

    Note that the "Prefix Length" value (number of bits in the netmask) cannot
    be changed, it must always be set to 21.

    (External Network 1 (EN-1) (eth3) should be filled in if NSP5.0 HW is being
     used. This is because an extra Gigabit cable is connected between IO1
     (eth3) and IO2 (eth3), to speed up the DRBD synching time between the IO
     processor disks. This is why this synchronization network is defined.)

- Commit the Network Configuration, as well as the previous IO2 configuration.

    Up to this step, the Back button can be used to revisit earlier choices.
    This will not be possible after clicking the Next button.

    Click Next to commit all previously entered parameters.

- In the "Reset processors" panel:
    Physically reset all processors in the zone, except IO2.
    Click Next.
    (If anything fails, see hint 6 below.)

- In the "Probing processors..." panel:
    Wait for all processors to be probed and configured.
    The panel will change automatically upon completion.
    Note that it may be necessary to manually reset some processors that fail to
    report in. Alternatively, disconnect/connect the failing processor(s).
    (Take no action on any printouts on the serial terminal to IO1, if any.)
      If this phase fails, i.e. if all processors are not probed within maximum
      10 minutes, see hint 2 below.

- OLD INFO FOR LSV? AND EARLIER! Will soon be removed!
    In the "Waiting for sitedb schema..." panel:
    This panel will not be visible if everything works well.
    The panel will change automatically upon completion.
    It may be that this panel will be removed in a later release.
      (If the "Waiting for sitedb schema" phase fails, i.e. if all processors
      are not dealt with within maximum 5 minutes, see hint 3 below.)

- OLD INFO FOR LSV? AND EARLIER! Will soon be removed!
    In the "Setting up processor pairs..." panel:
    Wait for all file server pairs to be configured.
    This step may take some time (see official document for details).
    No progress indication is provided during the
    operation (this will be fixed in a later release).
    The panel will change automatically upon completion.

    If this step takes longer than expected, check the site database file
    /opt/mirror/adm/etc/dbfile.xml as follows:
      The file servers are configured sequencially.
      A configured file server will have its Type value set to "FS".
      Completed file servers will have a pair_id in the partition entry.
      When both processors in the pair are installed, the next pair will be
      installed.

      (Info from uabadas:
       All processors included in a pair, (two IOs?) and upto four FSs, will be
       installed here.
       The wizard will install the processors one by one, so it may take some
       time to finish this step.
       You can follow the processor pair installation phase by looking in the
       site database file (/opt/mirror/adm/etc/dbfile.xml) where you check the
       following: To start with, no tags identifying a processor pair exist.
       The wizard will add the tag "<tsp:ProcessorPair>" for a processor pair
       and then install both these processors. When the installation is ready
       for a processor, the tag "<tsp:pair_id>" will be added for that
       processor, indicating the pair name (io, fs1 or fs2).)

- In the "Configure any external interfaces." panel:
    Configure any external interfaces, as appropriate for the external VIP
    network(s).

    It is currently not possible to configure different gateways for VIP
    interfaces on the same IP network. I.e. if two interfaces are configured
    with the same network, they must also have the same gateway. This is a
    limitation in the first issue of the installation wizard. I have issued
    TR HE74553 for this. Still true after LSV12?

    Special considerations for Dicos processors apply:
    After the installation is completed, you must change the port names from
    ethX to fxpX or wmX for Dicos processors, via CLI or the TelORB Manager.
    Still true after LSV12?

    OLD INFO FOR LSV12 AND EARLIER! Will soon be removed!
    Fill in the following (use tab to select the next box) (example for to14,
    to11, to20 and to28), by first selecting the Networks tab (default):

      Networks (example valid for to14, to11, to20 and to28)
      --------
      Network          Prefix Length     Gateway
      192.11.0.0       24                192.11.0.1        (Already filled in if
                                                            NSP5.0 HW is used)
      134.138.184.0    21                134.138.184.1     (Already filled in)
      192.168.76.0     24                192.168.76.1
      192.168.77.0     24                192.168.77.2
      Repeat for each network/gateway to be configured.

    Then select the Interfaces tab and fill in the following VIP data:

      Interfaces (example valid for to14)
      ----------
      Interface            Address           Network (Auto filled in when Enter
                                                      is pressed)
      Proc_m0_s17: eth2    192.168.76.170
      Proc_m0_s19: eth3    192.168.77.171
      Repeat for each VIP interface to be configured.

      (In epct: i4ddCommand_1000 = "ddconfig i4dd0 Proc_m0_s17-eth2-192.168.76.1 Proc_m0_s19-wm1-192.168.77.2")

      Interfaces (example valid for to11)
      ----------
      Interface            Address           Network (Auto filled in when Enter
                                                      is pressed)
      Proc_m0_s15: eth2    192.168.76.200
      Proc_m0_s21: eth3    192.168.77.201
      Repeat for each VIP interface to be configured.

      Interfaces (example valid for to11  OLD!!! Remove at next installation!)
      ----------
      Interface            Address           Network (Auto filled in when Enter
                                                      is pressed)
      Proc_m0_s15: eth2    192.168.76.200
      Proc_m0_s17: eth3    192.168.77.201
      Proc_m0_s19: eth2    192.168.76.202
      Proc_m0_s21: eth3    192.168.77.203
      Repeat for each VIP interface to be configured.

      Interfaces (example valid for to20)
      ----------
      Interface            Address           Network (Auto filled in when Enter
                                                      is pressed)
      Proc_m0_s13: eth2    192.168.76.138
      Proc_m0_s15: eth3    192.168.77.139
      Repeat for each VIP interface to be configured.

      Interfaces (example valid for to28)
      ----------
      Interface            Address           Network (Auto filled in when Enter
                                                      is pressed)
      Proc_m1_s17: eth2    192.168.76.80
      Proc_m1_s19: eth2    192.168.77.81
      Repeat for each VIP interface to be configured.

    The IO Interfaces tab cannot not be used for VIP links. This tab will soon
    be removed from the wizard as it is no longer valid.

    (Old info: If any of the IO processors are to be used as VIP routers, select
    the IO Interfaces tab and tick the appropriate checkbox(es) in the middle
    column.

     IO Interfaces (example valid for to28)
     -------------
     Interface (Auto filled in)          VIP      Network (Auto filled in)
     Proc_m3_s3: eth2 (134.138.18...              134.138.184.0/21; gw=134.1...
     Proc_m1_s1: eth2 (134.138.18...              134.138.184.0/21; gw=134.1...)

    (Old info: If you are installing a Dual1Mag or a Dual4Mag system, i.e. a
    two-processor system, this table will be blank (only headings visible).
    It should be possible to configure VIP addresses even for IO processors
    here, but this does currently not work. I have issued TR HE71524 for this.)

    Click Next.

  INSTRUCTIONS FOR LSV13 AND LATER:
    Fill in the following (use tab to select the next box) (example for to20),
    by first selecting the Networks tab (default):

      Networks (example valid for to20)
      --------
      Network        Prefix   Bearer     Boot   Family  Name
                     Length              Phase   
      192.11.0.0     24       EN-1       100    inet    external-1 (Already
                                                                    filled in if
                                                                    NSP5.0 HW is
                                                                    used)
      134.138.184.0  21       EN-0       100    inet    external-0 (Already
                                                                    filled in)
      192.168.76.0   24       VIP-EN-0   200    inet    vip-net-0x0
      192.168.77.0   24       VIP-EN-1   200    inet    vip-net-0x1

      Currently, it is not possible to jump between the boxes to change some
      settings. I will issue a TR for this.

      Repeat for each network/gateway to be configured.

    Then select the Interfaces tab and fill in the following VIP data:

      Interfaces (example valid for to20)
      ----------
      Interface           Logical net   IP address       Up   Config
      Proc_m0_s13: en-0   VIP-EN-0      192.168.76.138   v    autoneg
      Proc_m0_s15: en-1   VIP-EN-1      192.168.77.139   v    autoneg

      Repeat for each VIP interface to be configured.

    Then select the Ospf tab and for each interface which shall have a VIP
    router link, fill in the following:

      Ospf (example valid for to20)
      ----
      Interface          Router          "Hello"    "Dead"     Area ID   Gateway
                         Id              interval   interval
      Proc_m0_s13: en-0  192.168.76.138  10         40         10.0.0.0  192.168.76.1
      Proc_m0_s15: en-1  192.168.76.139  10         40         10.0.0.0  192.168.77.2

      (The Router ID, "Hello"interval and "Dead"interval are auto filled in.)

      Repeat for each VIP interface to be configured.

    The IO Interfaces tab is only informational. It shows the configuration of
    the external interfaces of the IO processors.
    You do not need to change anything in this tab.

- In the "Current Zone Definition / Zone Browser" panel:
    This panel is mainly for troubleshooting purposes and to be able to verify
    previously entered parameters.

    Click Next.

    The CW/OS epct files will be generated.

- In the "CW&OS Configuration Wizard Completed" panel:
    If you e.g. want to remove SS7 stuff from the epct file to prevent the
    SS7 wizard from starting when clicking the Finish button, do this now (if
    not already done).

    Click Finish.

    The TSP5 configuration wizard will be closed.

- Other subsystem wizards may start, depending on if SS7 and/or Node Management
  is/are included in the installation or not. (E.g. in a LinuxOnly Micro system,
  the SS7 wizard will not start.)
  Instructions for configuring SS7 and/or Node Management are not included in
  these guidelines.
  Follow the official installation instruction document "TSPn Runtime
  Installation Instruction..." to configure SS7 and/or Node Management.
  Thereafter you can proceed with the next step.
  NM example:
    Panel: "Fault Management - SNMP Client Management"
           Client properties, IP address: 134.138.83.80  Port: 161
           Click "Create new client".
           Fill in Client name, e.g. to20. Click OK.
    Panel: "Certificate configuration"
           Click "Use Demo Certificate". Keep the default values.

- If you get the following result window:
  "Warning
   Installation failed.
   The node configuration wizard returned an error code (22)...",
  an epct-error (system building error) has probably occurred.
  To verify what the cause of the error is, see Hint 8 below.
  After fixing the error(s), as explained in Hint 8 below, just continue the
  installation by following the instructions below.
  If the error(s) could not be fixed, it is recommended to abort the
  installation and start all over again (after finding out what is wrong).

- Any other optional application wizards may start at this point, if you have
  included any optional add-on application runtimes.

- The "Node configuration done" dialog box appears.
    Do not click "OK" in this dialog box yet!

- Ensure that the serial terminal is connected to IO2's serial port, as it will
  be needed shortly.

Installing from DVD
- If not already done, physically remove the DVD from the DVD drive.

Installing from DVD or installation server
- Click OK in the "Node configuration done" dialog box.
    The installer will now perform the steps in "Finishing Basic Installation".
    Thereafter, the installation window (VNC server) will be closed and IO2 will
    be ordered to reboot.

    Proceed with the next step as soon as IO2 starts to reboot.

Installing from DVD
- Change the BIOS settings for IO processor 2 (by using minicom, connected
  above), so that it will boot from disk:
    - Immediately when IO2 starts to reboot, hit Del (and/or Backspace) on the
      keyboard, with the cursor in the valid minicom window.
      This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "Boot" -> "Boot Device Priority".
      o Set "1st Boot Device" to "SM-FUJITSU MHT2040"
        (NSP5.0: #20 ID00 LUN0 FUJITSU MAP3147NP) or equivalent.
      o Verify that "2nd Boot Device" is set to "Disabled".
      o Press Esc and then save the changes and exit.

Installing from installation server
- Change the BIOS settings for IO processor 2 (by using minicom, connected
  above), so that it will boot from disk:
    - Immediately when IO2 starts to reboot, repeatedly hit Del (and/or
      Backspace) on the keyboard, with the cursor in the valid minicom window.
      This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "BIOS FEATURES SETUP" -> "Boot From LAN First" -> "None".
      o Make sure that "Boot Sequence" is set to "SCSI,C,A".
      o Press Esc and then save the changes and exit (as described earlier).

- Physically, disconnect the installation server from the SCB.

Installing from DVD or installation server
- Wait until IO2 has started, i.e. until you get a login prompt.
  No manual intervention is required.

  (The information "To abort waiting enter 'yes'..." appears in IO2's minicom
   window. Normally, one should not act on this, nor is it safe to do so.
   However, in this particular case, it is safe to answer "yes" and press Enter
   in the serial terminal. This may speed up the startup with a few minutes.
   I normally wait for the loading to continue (approximately 1 minute) instead
   of answering yes.)

- Finalize the IO1 installation by pressing the reset button on IO processor 1
  and then, immediately, hit Del (and/or Backspace) repeatedly on the keyboard,
  with the cursor in the valid minicom window. This will take you to the BIOS
  configuration menu.

- Change the BIOS settings for IO processor 1 (by using minicom, connected
  above), so that it will boot from disk as described for IO2 above
  (NSP4: SM-FUJITSU MHT2040) (NSP5.0: #20 ID00 LUN0 FUJITSU MAP3147NP).
  Also set "2nd Boot Device" to "Disabled".

- Wait until IO1 has started, i.e. until you get a login prompt.
  No manual intervention is required.

  (The information "To abort waiting enter 'yes'..." appears in IO1's minicom
   window. Do not act on this, just wait for the loading to continue.)

((- The following instruction should normally not be followed:
      Physically disconnect the Kickstart Server (ulinpc52) from the lowest
      connector on the front panel of IO processor 2.
      Connect the original cable to this connector (otherwise you will not be
      able to externally connect to IO2).))

- The installation is now completed.
  However, some post installations must probably be performed. Follow the
  official installation instruction document to complete the post installations.
 
  The system should be up and running. Verify this by following the instructions
  below. If the system is not up and running, you may have to manually reset all
  processors (except the IO processors).

Verify that the system is up and running and set up a working environment
(EAB specific) and start STS, LoadViewer and TelORB Manager
-------------------------------------------------------------------------
- Open a new shell window with e.g. the name toXXio1 and from that window, log
  in to IO1:
    ssh -X telorb@toXXio1                    (Adjust XX or use IO1's IP address)
    Password: telorb  (Password for root: rootroot)

- Open a new shell window with e.g. the name toXXio2 and from that window, log
  in to IO2:
    ssh -X telorb@toXXio2                    (Adjust XX or use IO2's IP address)
    Password: telorb

- On IO2: Verify that the system has reached Total Functionality, i.e. that all
  processors are up and running:
    grep -i 'total func' /opt/telorb/axe/tsp/consolelogs/*

  If you do not get a printout or if you get the following printout, you have
  to physically reset ALL processors in the system, excluding the IO and file
  server processors.
    "ERROR: Couldn't load total functionality - initial start is hanging."

  (Note that the log entries for the "Total functionality started"-printouts
   will expire after a while, so this verification can only be performed shortly
   after the installation has completed.)

- On IO2: Run the ping_all command to verify that all processors answers on a
  ping request:

    ping_all

  (It may be worthwhile to also run the ping_all command on IO1.)

- On IO2: Start the processor consoles (STS):

    STS_console --font 6x10 --max 99

    Alternatively:
      STS_console --font 6x10 --config /opt/telorb/axe/loadingGroup01_1/to14.config

      (If the complete system is not up and running, this may fail and will
       give the following printout:
       "-bash: STS_console: command not found")

      (You may have to use "tcsh")

- On IO2: Verify that the DRBD synching procedure is in progress (or finished),
  i.e. verify that IO1 gets synchronized with IO2:
    cat /proc/drbd

    Example of printout:
    "0: cs:SyncingAll st:Primary/Secondary ns:16082452 nr:0 dw:70876 dr:16272081 pe:0 ua:0
             [==>.................] sync'ed: 12.5% (110002/125696)M
             finish: 3:02:59h speed: 10,312 (9,963) K/sec"

    IO2 should be Primary and IO1 should be Secondary (which "Primary/Secondary"
    indicates).

    If you get the alarm "IO Processors Not Redundant" from both IO processors
    after the synching has been ongoing for approximately 20 minutes, this is
    normal. When the synchronization is finished, the alarm will automatically
    be cleared.
    This alarm should normally only be seen after an initial installation and
    when replacing an IO, or an IO outage.

- Only valid for NSP 5.0: If you have installed an NSP 5.0 system, it is
   possible to speed up the DRBD synching via the Gigabit link which the IO
   processors are equipped with (en-1, eth3). Do as follows on IO2:
    - Verify that IO2 is primary:
        su -
        Password: rootroot
        drbdsetup /dev/drbd0 state
        If the output is "Primary/Secondary", IO2 is primary.

   - Show the sync rate (among other things):
       drbdsetup /dev/drbd0 show

   - Set the synchronization speed to 30MBytes/second:
        drbdsetup /dev/drbd0 syncer -r 30M

   - Wait until the synchronization is finished.
     Then restore the synchronization speed back to the default value
     8MBytes/second:
        drbdsetup /dev/drbd0 syncer -r 8M
     DO NOT FORGET THIS, especially if you continue with the post
     installations!!!

   - Leave su mode:
       exit

- Also check the synching status on one of the FS processors, if any, in each
  file server pair in the same manner as for the IO processors above.

- If you have installed a Dual1Mag or a Dual4Mag system, i.e. a two-processor
  system, you may have to configure the VIP interfaces after the installation
  is completed, i.e. at this stage. I have issued TR HE71524 for this.
  To do this, follow the instructions in "Add VIP interface (external) IP
  addresses to the Site Database file dbfile.xml using the sitedbclient".

- On IO2: Start the processor Load Viewer:
    win -ns -th platform-vip &
      -or-
    win -th 172.16.0.9 -th 172.16.0.137 -ns &        (Adjust IP addresses)
      -or-
    win -th 172.16.0.9 -ns &
      -or-
    win -ns &

      (If the complete system is not up and running, this may fail and will
       give the following printout:
       "-bash: win: command not found")

- Start the TelORB Manager on e.g. IO2 and check for any alarms:
    eprtsetup
    TelORBManager -alarms &
    Connect to the VIP address (platform-vip, 172.30.14.20 or to20)  (Adjust)

  If you want to start the TelORB Manager from the Node Management toolbox, do
  as follows:
    In a web browser:
      http://<vip_address_to_system>  (E.g. 172.30.14.20 for to20)
                                            (Mozilla requires https)
      Login as "jambala".
      Password: Pokemon1
      Click the TelORB Manager link in the lefthand frame.

  If you want to start the TelORB Manager from a terminal (your own WS or tos1
  (if using tos2, alarms and notifications will not be received) where the
  testbed is sourced by using the VIP address:
    source /ipims_dicos/BS2/tbWP14/Setup.csh  (Loadable Extras included)
      -or-  (previously)
    source /ipims_dicos/ipims_dicos20/BS2/tbAD15.6/IP_CONF_INFO/EnvSettings
    source /ipims_dicos/BS2/tbTEST15.0/IP_CONF_INFO/EnvSettings  (To get
      Loadable Extras)
    TelORBManager -alarms &
    Connect to the VIP address (platform-vip, 172.30.14.14 or to14)  (Adjust)

- If there are Dicos processors with VIP links in the system, their interface
  names eth2 and eth3 must be renamed to fxp1 and fxp0 (NSP4.1), or wm0 and wm1
  (NSP5.0), or fxp0 and fxp1 (NSP4.0), respectively.
  To accomplish this, either use the TelORB Manager (if possible) or use the
  Command Line Interface (CLI). Instructions for this can be found in the
  official installation instruction document "TSPn Initial Installation
  Instruction ...".
  Remember to also update the /var/opt/tsp/epct/E10cwos_initial.epct file
  with the new interface names.

- If you need to rebuild and initial load the system, to e.g. also get software
  and pool allocations for the TSP Reference Application (traffic generator), do
  this before performing the post installations. Otherwise you will have to
  perform the post installations once more after the initial load. (The post
  installations will be removed at an initial load (also after an IO upgrade?)

- Perform the Node Management post installations according to the official
  installation instruction document "TSPn Initial Installation Instruction ...".

The installation is now complete, but you may want to perform some completion
tasks as follows:

- Exit minicom for all serial terminals:
    Ctrl-a x
    "Leave Minicom?"
    Yes (Enter).

- Disconnect all serial terminals.

- Log out from the workstation hosting the VNC server, e.g. the Kickstart Server
  (ulinpc52, 134.138.184.175).

- Close any terminal windows which will not be used any more.

(- After the installation is completed, it is not
   possible to create a backup, because of erroneous
   directory and file permissions below and including
   e.g. /opt/mirror/loadingGroup01_1 ("root   root"
   and not "telorb   telorb").
   Workaround command to be issued on IO2:
    chown -R 101:501 /opt/mirror/loadingGroup01_1)

If an installation server has been used, modify the NTP IP address to e.g.
134.138.226.13 in /opt/mirror/adm/etc/dbfile.xml tag <tsp:TimeServer >.

If required, change a value (e.g. for VIP interfaces) in the Site Database
(dbfile.xml) on the primary IO by using the sitedbclient.

Note: If you want to use IPv6 traffic in the initially loaded system, you have
      to change the VIP address and make some adjustments to your epct file and
      then load your system again. Instructions for how to accmplish this can be
      found in:
      Set up VIP for IPv4/IPv6 and generate traffic. 


Hint 1 
------
Problem: How to copy a file (e.g. dbfile.xml) from IO2 to the Kickstart Server
         (e.g. 192.168.11.1) during the installation.
Action:  Perform the following:
           scp dbfile.xml telorb@192.168.11.1:
           Password: <TelORB_password_for_the_Kickstart_Server>

           The file will end up in the root directory on the Kickstart Server,
           i.e. at /home/telorb/.


Hint 2
------
Problem: Not possible to probe all processors.
Action:  Open an xterm window in the VNC-viewer and check which processors have
         been added to the site database (SiteDb) as follows:
         - Click the square with a bold dot in it at the upper left corner of
           the "TSP5 Configuration Wizard" panel, to iconize the panel.
         - Click the icon at the upper left corner of the "YaST2..." panel, to
           iconize the panel. (To make this work, you may have to move the
           panels around, so that the upper left corner of the two panels do
           not overlap each other.)
         - Left-click anywhere in the VNC-viewer. A menu will open up.
           Select Xterm.
         - In the Xterm window (note that it takes a while before the
           processors are written into the dbfile.xml file):
             chroot /mnt
             cd /opt/mirror/adm/etc/
             grep Proc_ dbfile.xml
             Ctrl-mid-mouse-click   (enable scrollbar)
             grep Proc_m0_s dbfile.xml
             grep Proc_m1_s dbfile.xml
             grep Proc_m2_s dbfile.xml
             grep Proc_m3_s dbfile.xml
             grep Proc_m4_s dbfile.xml

         - Check the number of processors which have been written into the
           SiteDB file:
             cd /opt/mirror/adm/etc/
             grep Proc_ dbfile.xml | wc -l      (line count)

         - Check if DHCP is running (it should be):
             cd /etc/init.d/
             ./dhcpd status
             Should show: "Checking for DHCP server:                  running"


Hint 3
------
- If the "Waiting for sitedb schema..." phase (directly after the probing)
  fails, you can act as the probe kernel and send in changes to the SiteDb
  file dbfile.xml as follows:
    Find out where TspSiteDbClient.LM_D274.elf.R1A04.i686-linux is located
    (adjust R1A04):
       cd
       find . -iname '*SiteDbClient*'
         E.g. ./mirror/loadingGroup01_1/PXE_X86PC/UNDI/tsp/TSP/TspSiteDb/TspSiteDbClient.LM_D274.Code.R1A04.i686-linux
           
     Make the TspSiteDb/TspSiteDbClient.LM_D274.Code.R1A04.i686-linux file
     executable:
       chmod 555 ./mirror/loadingGroup01_1/PXE_X86PC/UNDI/tsp/TSP/TspSiteDb/TspSiteDbClient.LM_D274.Code.R1A04.i686-linux

     For each processor that has failed, fill in <...> in the command
     lines below and send the command (adjust what to modify in the command
     lines below):
             ./mirror/loadingGroup01_1/PXE_X86PC/UNDI/tsp/TSP/TspSiteDb/TspSiteDbClient.LM_D274.Code.R1A04.i686-linux \
       > modify Processor hwid=<hwid> \
       > EthernetInterface macaddress=<macaddress> \
       > in_addr 172.16.8.0

       (\ means tells that the command is continued on the next line (>)
        after enter has been given)
       (<hwid> = e.g. 00:20:ce:c8:12:f0)
       (<macaddress> = e.g. 00:20:ce:c8:12:f1)
       (in_addr = 172.16.8.0 for eth1 if eth0 has been given 172.16.0.0, i.e.
        the base address is used)


Hint 4
------
If you want to change the epct file to suit your system, do as follows.

Either edit an existing epct file on IO2:
- In the VNC-viewer:
  Click the square with a bold dot in it at the top left corner of the YaST2
  panel, to iconize the panel.
- Left-click anywhere in the VNC-viewer. A menu will open up. Select Xterm.
- In the Xterm window (adjust the Runtime directory to valid directory):
    cd /mnt/opt/mirror/runtimes/TelORB-R15-LSV509C-Runtime/config/epct/
      (alt. cd /opt/mirror/runtimes/TelORB-R15-LSV509C-Runtime/config/epct/)
    ls -l    (List all epct template files (the same epct template files as
              displayed in the "Select Node Type Template" area of the YaST2
              panel be listed))
- Use the VI editor in the opened xterm window to edit one of the template files
  to suit your system as follows:
    First, copy the template file to modify, and substitute e.g. "template" to
    "original".
    vi <file_name.template>        (Do not alter the name of the file when
                                          saving it)

    -or-

Copy an epct file from outside IO2 to IO2:
- In the VNC-viewer:
  Click the square with a bold dot in it at the top left corner of the YaST2
  panel, to iconize the panel.
- Left-click anywhere in the VNC-viewer. A menu will open up. Select Xterm.
- In the Xterm window:
    cd /mnt/opt/mirror/runtimes/TelORB-R15-LSV509C-Runtime/config/epct/
      (alt. cd /opt/mirror/runtimes/TelORB-R15-LSV509C-Runtime/config/epct/)
    ls -l    (List all epct template files (the same epct template files as
              displayed in the "Select Node Type Template" selection area of
              the YaST2 panel be listed))
- Since you have to substitute an existing epct template file on IO2 with the
  epct file to be copied, first change the name of the epct template file you
  wish to select in the "Select Node Type Template" panel. E.g. add ".original"
  to the end of the file name, e.g.
    mv <file_name><file_name.original>.

- Copy the valid epct file from outside IO2 to IO2 (still from xterm), e.g.:
    scp telorb@134.138.186.nn:/home/dicoshack/Hack/uabmsu/epct/NSP4.x_Midi_CwosLinuxOnly.epct.template .
- Change the name of the copied epct file, if necessary. The name must be a
  name of one of the epct template file in the "Select Node Type Template"
  panel.
- Edit the file, if necessary.
- Exit the Xterm window:
    exit
    exit


Hint 5
------
If "External Net B" is not filled in by the user
(during internal and external network configuration
for the IOs), the eth3 interface for the IO processor
gets the value "null" in the file
/opt/mirror/adm/etc/dbfile.xml.
This may lead to that the initial load of the IO
processor fails.
I have not issued a TR for this, since Sverker fixed
this error directly after I explained this to him.
Solution delivered to tbAD15.2.
Workaround commands to be issued on IO2:
  /etc/init.d/sitedb stop
  /etc/init.d/dhcpd stop
  emacs /opt/mirror/adm/etc/dbfile.xml &
  Find the word "null" and replace it with "0.0.0.0".
  Save the file.
  /etc/init.d/sitedb start


Hint 6
------
If anything fails in e.g. the probing phase, the cause of the failure may be
found in one of the y2log files, as follows.
On IO2 (from e.g. an xterm window opened in the wizard:
  su   
  Password: 
  cd /var/log/YaST2/
  ls -l
    total 242
    drwx------    2 root     root         1024 May 27  2004 .
    drwxr-xr-x    6 root     root         1024 Jan  3 03:45 ..
    -rw-r--r--    1 root     root         1184 May 27  2004 y2log
    -rw-r--r--    1 root     root        23675 May 27  2004 y2log-1
    -rw-r--r--    1 root     root        51202 May 27  2004 y2log-2
    -rw-r--r--    1 root     root        51344 May 27  2004 y2log-3
    -rw-r--r--    1 root     root        51517 May 27  2004 y2log-4
    -rw-r--r--    1 root     root        51704 May 27  2004 y2log-5
    -rw-r--r--    1 root     root         2436 May 27  2004 y2loggrub
    -rw-r--r--    1 root     root          350 May 27  2004 y2logmk_initrd
    -rw-r--r--    1 root     root          199 May 27  2004 y2start.log-initial
  grep dhcpd y2log*


Hint 7
------
If the VNC viewer hangs, try to log in from e.g. a Linux processor, e.g.
ulinpc52, as follows:
  vncviewer to28io2:1
  Password: <Enter the VNC authentication password> tel123orb


xx. To be able to use the TelORB processor LoadViewer
    via the VIP address, i.e. to execute "win -th"
    using the VIP address (TCP port 10000), the
    following line could be added in the epct file
    or via the TelORB Manager:

      Ipv4 IPPROTO_TCP 10000 roundRobinDistributor

    (TR HE65962)


Hint 8
------
Problem: "Warning
          Installation failed.
          The node configuration wizard returned an error code (22)..."
Action:  Open an xterm window in the VNC-viewer and execute the epct command
         manually as follows:
         - Left-click anywhere in the VNC-viewer. A menu will open up.
           Select Xterm.
         - In the Xterm window:
             chroot /mnt
             cd /var/opt/tsp/epct/
             /opt/telorb/bin/eprtsetup
             epct -v -c -F -X -f loadingGroup01_1 -d /opt/telorb/axe/ E*
         If epct fails, check the reason for the failure, correct it, and
         rerun the epct command.
         Upon successful completion of the epct command, close down xterm and
         click "Ignore" in the Warning window.
         Thereafter, the "Node configuration done." window should appear.
         If so, just continue the installation.


Hint 9
------
To log in to IO2 during the installation (for whatever reason) do as follows:
  Open a new xterm window on the workstation running the VNC viewer.
  In the opened xterm window, log in to IO2 as root:
    ssh -X root@<IP_addr_of_IO2>
    Password: tel123orb


Old info to perhaps be removed
------------------------------
- In xterm:
    chroot /mnt
    /etc/init.d/portmap restart

---- Old start 1 ----
 Interface           Address             Prefix   Network           Gateway
                     (From telorb.conf)  Length   (Auto filled in)  (From epct)

 Proc_m1_s13: eth2   192.168.76.160      21       192.168.72.0      192.168.76.1
 Proc_m1_s13: eth3   192.168.76.160      21       192.168.72.0      192.168.77.1

 Proc_m1_s15: eth2   192.168.76.161      21       192.168.72.0      192.168.76.2
 Proc_m1_s15: eth3   192.168.76.161      21       192.168.72.0      192.168.77.2

It should be possible to assign different gateways to different interfaces.
As it works now, it is only possible to assign different gateways to different
networks. TR?
---- Old end 1 ----

---- Old start 2 ----
(( - If it is possible to log in to IO1, verify that the DHCP service is stopped
     (as root) (Alternatively, make IO1 unavailable):
       su
       psw
       /etc/init.d/dhcpd status
       If dhcpd is running:
         /etc/init.d/dhcpd stop ))
---- Old end 2 ----

---- Old start 3 ----
Configure any external interfaces:
    Old info to be removed:

   Interface          Address             Prefix  Network           Gateway
                      (From telorb.conf)  Length  (Auto filled in)  (From epct)

   Proc_m1_s13: fxp1  192.168.76.160      24      192.168.76.0      192.168.76.1

   Proc_m1_s15: fxp0  192.168.77.161      24      192.168.77.0      192.168.77.2

    Repeat the procedure for each external interface to be configured.

    -- -- -- --
    Example for 2 processor cluster, to14 (does not currently work, see TR):
    Interface         Address             Prefix  Network           Gateway
                      (From telorb.conf)  Length  (Auto filled in)  (From epct)

    Proc_m0_s1: eth3  192.168.76.160      24      192.168.76.0      192.168.76.1

    Proc_m0_s5: eth3  192.168.77.161      24      192.168.77.0      192.168.77.2
    -- -- -- --

    (When entering the external interfaces for e.g. VIP, and the user wants to
     remove a line of inputs, this is not possible. If clicking the Next button
     in this case, the Site Database gets corrupt. This should be fixed in the
     next version of the wizard. Already fixed?)
---- Old end 3 ----

(Updated: 2004-06-09)

Build on IO and initial load
----------------------------
Preferably, build (epct) the system on IO2, since this is where the epct files
initially resides (below /var/opt/tsp/epct/).
However, as long as the system is up and running (IOs synching or done with IO
synching), it is possible to build (epct) on any of the IOs.

In other cases, build on the primary IO.
  (If you want to make IO2 primary, and the system is up and running and done
   with IO synching, you can reload IO1.)
  (Note that the epct files are initially located only on IO2, but it is
   possible to copy them to the other IO processor (see instructions for
   this below).)

- Log in to the IO processor to build on:
    ssh telorb@toXioY              (Adjust toXioY to valid system and IO)
    Password: telorb

- Check which IO is primary/secondary:
    cat /proc/drbd

- To be able to access e.g. testbed and tbTEST software outside the IO
  processor follow the instructions at
  Mount EAB CW/OS lab environment on IOs.

- Only valid for TSP 5.0, i.e. not for TSP 5.1 and onwards:
  Delete current codeArchive:
    cd /opt/telorb/axe/loadingGroup01_1  (cd /opt/mirror/loadingGroup01_1)
    rm -rf codeArchive
    rm -rf codeArchive            (If you get reply "rm: cannot remove directory
                                   `codeArchive/IO.CXP9010596_1': Directory not
                                   empty", this is because .nfs files are being
                                   created whilst removing the directory)
                         (You may also want to delete the contents of the backup
                         directory and all Processor software directories:
                           rm -rf backups/
                           rm -rf Proc_m*)

    (If you accidently delete the codeArchive directory or all of its content,
     and you thereafter build the system, the IO_CXP will be missing when all
     is done, since IO_CXP is not created by the epct command. However, there
     are ways to restore it (info provided by Roger Nilsson, 2005-05-11) as
     follows.
       After initial installation:
         > eprtsetup
         > epgetpath LM/D301
         > su
         > update_yast_files --cxp=<path_to_io_cxp>
       After IO upgrade:
         > su
         > update_yast_files --cxp=/boot/upgrades/IO_CXP)

- Verify that the epct directory has telorb privileges:
    cd /var/opt/tsp
    ls -l epct

    If not, change the privileges:
      su
      Password: rootroot
      chown telorb:telorb epct
      exit

- Verify that all required epct files exist in the epct directory:
    cd /var/opt/tsp/epct/
    ls -l

- If you need to add further epct files, e.g. to also include the TSP Reference
  Traffic Application, use e.g. the scp command as follows:
    scp telorb@134.138.186.45:/home/dicoshack/Hack/uabmsu/to11_42processors_tsp5_files/epct/TSPRefApp.epct .
                                                    (Adjust IP address and path)
    Password: tsP4ever

- If you need to adjust any of the epct files, do so.

- Select one of the following software locations to fetch the software from:

  o Software located on IO (from the initial installation):
    (Use this option after installation from DVD or KS, i.e. load from the
     runtime SW which has been provided from the DVD/KS.)

    Verify that the Runtime software (distribution) exists on the IO:
      ls -l /opt/telorb/axe/runtimes/          (E.g. TelORB-R15-LSV510-Runtime)

    Source the distribution on the IO, as telorb user:
      cd /var/opt/tsp/epct/
      /opt/telorb/bin/eprtsetup

  o Software from the distribution in the UAB environment:
    (Use this option if you want to load from different runtime software
     (distribution) than exists in the runtime environment on the IO.)
      tcsh
      cd /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/TelORB-R15-LSV510/TelORB-R15-LSV510-Runtime/
      source setup.csh
      cd /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/TelORB-R15-LSV510/TelORB-R15-LSV510-SDK/
      source setup.csh
      cd /var/opt/tsp/epct/

  o Software from a work package (testbed), e.g. tbWP026 (SW for TelORB runtime,
    sdk and test is fetched):
    (Use this option if you want to load from different runtime software
     (testbed) than exists in the runtime environment on the IO.)
      tcsh
      source /ipims_dicos/BS2/tbWP026/tsp_deliverables/Setup.csh
        -or-   (Investigate which of these that should be used!!!)
      source /ipims_dicos/BS2/tbWP14/Setup.csh
      (Note that the TSP Reference Traffic Application as well as other test
      applications are automatically sourced from the TelORB test distribution
      with this source command, i.e. there is no need to source these
      separately.)
        (Previously, for TSP 5.0: source /ipims_dicos/ipims_dicos20/BS2/tbAD15.7/IP_CONF_INFO/EnvSettings)
      cd /var/opt/tsp/epct/

      (If you need to source a "snapshot" of a work package, here is an example:
       source /ipims_dicos/.snapshot/nightly.1/BS2/tbWP026/tsp_deliverables/Setup.csh)

- Only valid for TSP 5.0, i.e. not for TSP 5.1 and onwards:
  Clear any epconfig settings:
    epconfig d -a

- Valid for TSP 5.1, and possibly also for TSP5.0:
  The TSPRefApp IDP will automatically be included if you are building from
  a work package testbed, e.g. tbWP124, so no setting is required.
  If you want to run on the local eprtsetup-environment on the IO processor,
  do the following to get the TSPRefApp IDP software:
    epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV11/tsp-LSV11-test/system/TelORB/*
    (Adjust LSV to valid LSV)

- Only valid for TSP 5.0, i.e. not for TSP 5.1 and onwards:
  Select one of the following software locations to include the TSP Reference
  Traffic Application from:

  o Software located on IO (from the initial installation):
      epconfig s -r /opt/telorb/axe/runtimes/TelORB-R15-LSV510-Runtime/examples/IDP_DEM101_R3A04-Demo2/
        or
      epconfig s -r /opt/mirror/runtimes/TelORB-R15-LSV510-Runtime/examples/IDP_DEM101_R3A04-Demo2/
                                       (Adjust LSV510 and R3A04 to valid values)

  o Software from a tbTEST, e.g. tbTEST15.0-LSV510:

      tcsh                (If not already set)
      source /ipims_dicos/BS2/tbTEST15.0-LSV509C/IP_CONF_INFO/EnvSettings

- Add TLMs, if any (example for LSV510 TLM package 2004-11-01):

  - Delete all epconfig settings, create epws directory and set environment
    variable:
      epconfig d -a
      mkdir epws
      setenv EP_WORKSPACE `pwd`/epws

TLMs:
/ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510

Do the following to use the available TLMs from CW/OS. Please note that the
order is important.

# LSV509C2:Smooth upgrade fails on Maxi node,CA De2DisPT
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HE96097_0/*LM
# LSV509C:Full sync between IOs after every zone reload
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HE96328_0/*LM
# cwos510: DUG: Timeout on setup ack aborting appl. process
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF12756_0/*LM
# LSV509 Initial load failed, JVM capsule abortion
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HE88345_1/*LM
# LSV509C different time displayed on IO, Dicos, Linux
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HE98846_0/*LM
# LSV509_iso20 Failed to get host from name Proc_m0_sXX.tspint
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF12349_0/*LM
# LSV509C CA De2VipAccessPt at Procreload during highload ->ZR
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HE99508_0/*LM
# cwosLSV510: PM-Probe tries to load LM frow wrong IDP
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF19936_0/*LM
# LSV509_pa20, Hardware trap in ss7driver
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HE96856_0/*LM
#    LSV509C3: Reload of second loader causes problems in IO2
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF11454_0/*LM
#    TSP5.0: DRBD full sunc after redundancy upgrade of I/O
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF20739_0/*LM
#    cwos510: Replacing TP with external interfaces does not work
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF21652_1/*LM
# cwos510: Hardware Trap during redundancy upgrade
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF12807_1/*LM
#  TADE 5.0 LSV 511: not possible to generate rtid:s
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV510/HF26069_0/*LM

- Build:
  Normally, use the "-d /opt/telorb/axe/" option to point out where to write the
  code. If, for example, the TSP part is stopped on the IO where the build will
  be carried out, use the "-d /opt/mirror" option instead.

    epct -v -c -F -X -f loadingGroup01_1 -d /opt/telorb/axe/ E10Name.epct E00NodeType.epct E10cwos_initial.epct E30nm.epct
      (Previously, for TSP 5.0: epct -v -c -F -X -f loadingGroup01_1 -d /opt/telorb/axe/ E10Name.epct E00NodeType.epct E10cwos_initial.epct TSPRefApp.epct)
                                (Adjust the epct file names to suit your system)

    or

  epct -v -c -F -X -f loadingGroup01_1 -d /opt/mirror E10Name.epct E00NodeType.epct E10cwos_initial.epct TSPRefApp.epct

    or use the original build command executed by the wizard

  epct -vFc -f loadingGroup01_1 -d /opt/telorb/axe /var/opt/tsp/epct/E*.epct
                                                                (Note "E*.epct")

- Verify build result.

- Perform an initial load by either starting a zone reload from the
  TelORB Manager (if possible) or by physically pressing the reset buttons of
  the processors.

  If a processor does not load and you want to replace it hardwarewise, you must
  first delete the processor entry in the site database file by using e.g. the
  sitedbclient command, for the replacement processor to start probing.
  In the probing phase, the site database file will be automatically updated
  with data about the replacement processor.

  See instructions for this at:
  Modify the Site Database file dbfile.xml using the sitedbclient.


Hints
-----
- If you have sourced something (e.g. tbTEST) and want to get rid of this
  sourcing, you can either log out from the IO processor and then log in again
  in the same window, or you can open a new window and log in to the IO
  processor.

- To do epct, you may have to set EP_CONFIGPATH, e.g.:
    setenv EP_CONFIGPATH /ipims_dicos/BS2/tbLSV15/conf:/ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV14/tsp-LSV14-test/system/conf:/ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV14/tsp-LSV14-Runtime/system//conf:/ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV14/tsp-LSV14-SDK/system//conf:/ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV14/cwos-LSV14-src/system/conf:/ipims_dicos/BS2/tbArchiveTSP5.1/system/conf_R1A05

- In LSV15, WP140 you have to add the following VIP related CXPs to your epct
  file:
    SOFTWARE CXP9011426/1;          // VipCommon
    SOFTWARE CXP9011424/1;          // VipDicos
    SOFTWARE CXP9011423/1;          // VipLinux 

(Updated: 2005-01-11)

- Start LoadViewer externally using the VIP address:
    win -th 172.30.14.11 -ns &       (Adjust VIP address to suit your system)

- Start LoadViewer on any IO processor:
    win -ns -th platform-vip &          (As used in CW/OS Initial Installation)
      -or-
    win -ns &
      -or-
    win -th 172.16.0.1 -th 172.16.8.5 -ns &        (Adjust IP addresses (to14))
      -or-
    win -th 172.16.0.129 -th 172.16.9.131 -ns &    (Adjust IP addresses (to28))

(Updated: 2004-10-21)

General (Info from uabadas, e-mail 2005-04-12)
-------
At startup, the processors will send the console information to their serial
interface, so you must have a serial cabel connected to receive the information.

In the middle of the startup, the flow will be moved from the interface to one
of the IOs, normally IO2.

The IO collects the information from all processors and creates a log file for
each processor. The files are located in "/opt/telorb/axe/tsp/consolelogs/" on
the IO and are called Proc_mX_sY. The file is filled until it reaches 2 Mbyte.
Then it is renamed to Proc_mX_sY.b and a new Proc_mX_sY is created. Existing
Proc_mX_sY.b files will be overwritten.

The command that starts this work on the IO is "STSsw". Try "STSsw -h" to read
more about the command.


Start STS consoles on any IO processor
--------------------------------------
Start STS consoles on any IO processor (previously the IP address was hardcoded
so that it was only possible to start STS on IO2):
  STS_console --font 6x10 --max 99       (As used in CW/OS Initial Installation)
    -or-
  STS_console               (Uses default font and default config file as input)
    -or-
  STS_console --font 6x10   (Uses default config file as input)
    -or-
  STS_console --font 6x10 --config /opt/telorb/axe/loadingGroup01_1/to28.config --max 99
                                       (Adjust to28.config to valid config file)


Close all STS consoles
----------------------
  STS_console --kill


Clear the processor log files
-----------------------------
Sometimes, e.g. when testing, it can be good to clear the log files, so it can
be for sure that the data in them belongs to the test. How to do this is
different if running TSP5.1 before or after LSV10, as follows:

  Before LSV10
  ------------
    On IO2:
      su
      /opt/telorb/etc/rc.d/init.d/STSswRpm stop
      rm /opt/telorb/axe/tsp/consolelogs/Proc*
      /opt/telorb/etc/rc.d/init.d/STSswRpm start

  LSV10 and after
  ---------------
    On IO2:
      ps -ef | grep STSsw
      rm /opt/telorb/axe/tsp/consolelogs/Proc*
      kill <pid received in ps command above>


Check status of STS (processor consoles)
----------------------------------------
Only valid before LSV10?
  su -
  psw
  /opt/telorb/etc/rc.d/init.d/STSswRpm status
    runningg for STSswRpm daemon:      (=STS running)


Start the STS process if it is not running
------------------------------------------
Only valid before LSV10?
  su -
  psw
  /opt/telorb/etc/rc.d/init.d/STSswRpm start

(Updated: 2004-06-09)

Normally, the TelORB Manager is started externally using the external VIP
interface, but it may also be started on any of the IO processors.

Either start the TelORB Manager from any of the IOs:
  TelORBManager -alarms &
  Connect to the VIP address (e.g. platform-vip, 172.30.14.XX or toXX)
                                              (Adjust XX to valid value)

or start the TelORB Manager from a local PC/workstation or on e.g. tos1 (do not
use tos2, since alarms and notifications may disappear), using the external VIP
address:

- Either source the work package testbed:
    tcsh
    source /ipims_dicos/BS2/tbWP026/tsp_deliverables/Setup.csh
      (Official delivery, where Java is not included. I.e. you may get a
       TelORB Manager where different areas overlap each other, since the
       Java version, which is present on the machine where the TelORB Manager
       is opened, will be used.)
      -or-
    source /ipims_dicos/BS2/tbWP14/Setup.csh  (Loadable Extras included)
      (Non-official delivery, where Java is included.)
      (Previously, for TSP 5.0: source /ipims_dicos/ipims_dicos20/BS2/tbAD15.7/IP_CONF_INFO/EnvSettings)

  or source the distribution (works?):
    cd /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/TelORB-R15-LSV510/TelORB-R15-LSV510-Runtime/
    source setup.csh
    cd /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/TelORB-R15-LSV510/TelORB-R15-LSV510-SDK/
    source setup.csh

  or source the TSP 5.0 testbed (previously):
    source /ipims_dicos/ipims_dicos20/BS2/tbAD15.6/IP_CONF_INFO/EnvSettings
    source /ipims_dicos/BS2/tbTEST15.0/IP_CONF_INFO/EnvSettings  (To get
    Loadable Extras)

    Connect to the VIP address (e.g. platform-vip, 172.30.14.XX or toXX)
                                              (Adjust XX to valid value)

- Source tbTEST (to get Loadable Extras):
    source /ipims_dicos/BS2/tbTEST15.0-LSV509C/IP_CONF_INFO/EnvSettings

- Start and connect the TelORB Manager:
    TelORBManager -alarms &
    Connect to the VIP address (e.g. 134.138.71.XX or 172.30.14.XX or toXX)

(Updated: 2005-03-16)

ssh -X telorb@ulinpc49 
Password: tsP4ever
cd /srv/ftp/pub/TSP5.1/LSV10/
ls -l
  -- Example of printout as of Mar 10 15:24:11 2005 --
  total 2398096
  drwxr-sr-x    8 telorb   50            240 2005-03-07 23:21 HF40324_3
  -rw-r--r--    1 telorb   50       316913900 2005-03-07 23:25 HF40324_3.tar.gz
  -rw-r--r--    1 telorb   50        5321643 2005-03-07 17:59 HF40324.tgz
  -rw-r--r--    1 telorb   50       330129052 2005-03-03 20:49 HF59197_2.tar.gz
  -rw-r--r--    1 telorb   50       330140266 2005-03-04 21:59 HF59197_3-tsp.tar.gz
  -rw-r--r--    1 telorb   50       50790493 2005-03-03 20:18 HF59682_1.tar.gz
  -rw-r--r--    1 telorb   50       25550260 2005-03-04 21:59 HF60072_1-tsp.tar.gz
  -rw-r--r--    1 telorb   50       21768253 2005-03-07 17:28 HF60358_0.tar.gz
  -rw-r--r--    1 telorb   50       11970094 2005-03-07 23:16 HF60572_1.tar.gz
  -rw-r--r--    1 telorb   50       21887946 2005-03-04 18:33 HFlibslp_0.tar.gz
  -rw-r--r--    1 telorb   50        4017360 2005-03-10 11:24 TLM_HF55549_2.tgz
  -rw-r--r--    1 telorb   50        8939520 2005-03-07 15:07 TLM_HF59030.tar
  -rw-r--r--    1 telorb   50        4577280 2005-03-07 16:45 TLM_TR_HF60343.tar
  -rw-r--r--    1 telorb   50       466142746 2005-03-10 11:22 TLM_wp14.1.tgz
  -rw-r--r--    1 telorb   50       855082908 2005-03-07 13:49 WP14_CWOS_Delivery.tgz
  -- End of example printout --

(Updated: 2005-05-18)

Basics
------
/opt/mirror/ points to the same location as /opt/telorb/axe/, but officially
/opt/telorb/axe/ should always be used.


Location of some basic files (TSP 5.1)
----------------------------
TelORB processor logs:
  /opt/telorb/axe/tsp/consolelogs       (or /data/tsp/consolelogs on primary IO)

Site Database file:
  /opt/telorb/axe/adm/etc/dbfile.xml
    -or-
  /opt/mirror/adm/etc/dbfile.xml         (This path should normally not be used)

Epct files:
  /var/opt/tsp/epct/                     (Epct files belonging to the system)
    -or-
  /opt/mirror/runtimes/TelORB-R15-LSV510-Runtime/config/epct/    (Location of
                               template epct files used at initial installation)

DHCP:
  /opt/mirror/adm/etc/dhcpd.conf


System info files (TSP 5.1)
-----------------
cat /proc/drbd		 (Check if synching is in progress or finished, and also
                          how much of the synching that is left.

cat /proc/meminfo        (Get memory information)


Error dump info files for Linux processors (TSP 5.1)
------------------------------------------
On IOs (collects info about all Linux processors):
/var/log/messages


DRBD synchronization information
--------------------------------
Verify if the storage devices on the IO and FS pairs are synchronized.
  On one of the processors in each file server pair (IO and/or FS):
    cat /proc/drbd

The system is vulnerable to single point failures until the disks have been
synchronized. This should be indicated by an alarm. However, if you want to
verify if the synchronization is in progress or finished, you can do this
manually, by entering the command above on one of the processors in each
file server pair (IO and/or FS).

The synchronization is not completed, if the result printout includes a progress
bar. If this is the case, the estimated time until completion is also included
in the printout.


Check NTP status and start NTP on IO processor (TSP 5.1)
----------------------------------------------
  date
  su
  Password: rootroot
  more /var/log/ntp                                       (Read NTP history log)
  /etc/init.d/xntpd status
    unusedng for network time protocol daemon (NTPD):          (NTP not running)
  /etc/init.d/xntpd start
    Try to get initial date (134.138.201.17) and time via NTP, 
    done    from 134.138.201.17 Proc_m2_s1
    doneting network time protocol daemon (NTPD)
  date
    Mon Oct 25 13:07:35 CEST 2004
  /etc/init.d/xntpd status
    runningg for network time protocol daemon (NTPD):          (NTP running)
  exit
    (If the alarm "Local time (NTP) client not reachable" is present for one or
     both IOs, a possible cause may be that NTP is not running on the IO
     processor(s), i.e. the command "./xntpd status" above shows "unusedng for
     network time protocol daemon (NTPD):". AFter starting NTP, it may take a
     few minutes before the alarm is cleared.)
  ps -ef | grep -i ntp
    -- Example of printout start --
    root      2429  2357  0 11:03 ?     00:00:00 /usr/bin/ntp-supervisor
    ntp       2705     1  0 11:03 ?     00:00:00 /usr/sbin/ntpd -c /etc/ntp.conf
    -- Example of printout end --

  You may also restart the NTP daemon as root as follows:
    /etc/init.d/xntpd restart


Check NFS status on an IO processor (TSP 5.1)
-----------------------------------
 Note that the NFS server should only be running on primary IO (FS?).
  su
  Password: rootroot
  cd /etc/init.d/
  ./nfsserver status
    runningg for kernel based NFS server:       (NFS running, printout valid
                                                 for primary IO)
      -or-
    unusedng for kernel based NFS server:       (NFS not running, printout valid
                                                 for secondary IO)


Check DRBD status (TSP 5.1)
-----------------
  /etc/init.d/drbd status
  cat /etc/drbd.conf

On IO (to20):
  /sbin/ifconfig -a
    tipct0: inet addr, e.g. "inet addr:172.16.32.129" for Proc_m1_s1 and
                            "inet addr:172.16.33.1"   for Proc_m2_s1
    tipct1: inet addr, e.g. "inet addr:172.16.39.254" = heartbeat address(?),
                                                        only on primary IO


Mount points on IOs (TSP 5.1)
-------------------
  mount
    /dev/sda7 on / type reiserfs (rw)
    proc on /proc type proc (rw)
    tmpfs on /dev/shm type tmpfs (rw)
    devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
    /dev/sda6 on /boot type reiserfs (rw)
    /dev/sda8 on /var type reiserfs (rw)
    172.16.39.254:/opt/mirror on /opt/telorb/axe type nfs (rw,udp,rsize=8192,wsize=8192,timeo=14,hard,intr,retry=3,addr=172.16.39.254)
    /dev/drbd0 on /opt/mirror type reiserfs (rw)            (Only on primary IO)
    nfsd on /proc/fs/nfsd type nfsd (rw)                    (Only on primary IO)


Start/Stop sitedb and other processes (TSP 5.1)
-------------------------------------
su -                (Important to be root when stopping and starting processes!)
Password: rootroot

/etc/init.d/sitedb status   (If running: "runningg for sitedb daemon:")

/etc/init.d/sitedb stop

/etc/init.d/sitedb start

exit

Example of other processes to be stopped/started in the same way as described
above (just swap "sitedb" to the valid process):
- dhcpd
- named
- nfsserver


Check which IO is Primary/Secondary (TSP 5.1)
-----------------------------------
Either log in to any of the IOs and enter the command:
  cat /proc_drbd
  If the result printout is "Primary/Secondary", this means that the IO that you
  are logged in to is Primary and the other IO is Secondary.
  If the result printout is "Secondary/Primary", this means that the IO that you
  are logged in to is Secondary and the other IO is Primary.

-or-

On any of the IOs:
  Log in to the IO processor as root (or use "su -" if you are already logged
  in):
    ssh -X root@<IP_address_of_primary_IO>

  Password: rootroot
  drbdsetup /dev/drbd0 state 
  If the result printout is "Primary/Secondary", this means that the IO that you
  are logged in to is Primary and the other IO is Secondary.
  If the result printout is "Secondary/Primary", this means that the IO that you
  are logged in to is Secondary and the other IO is Primary.


Start DRBD sync (TSP 5.1)
---------------
Start DRBD sync by entering the following command on the secondary IO:
  su
  drbdadm invalidate drbd0

Another way to start DRBD sync from primary IO:
  su
  drbdsetup /dev/drbd0 invalidate_remote

Another way to start DRBD sync from secondary IO:
  su
  drbdsetup /dev/drbd0 invalidate


Show synching configuration data (TSP 5.1)
--------------------------------
On IO1 and/or IO2:
  Log in to the IO processor as root (or use "su -" if you are already logged
  in):
    ssh -X root@<IP_address_of_primary_IO>

  Password: rootroot
  drbdsetup /dev/drbd0 show

  --- Start of example printout ---
  Lower device: 08:09   (sda9)
  Meta device: internal
  Disk options:
   size = 130633319 KB
  Local address: 172.16.32.65:7788
  Remote address: 172.16.32.33:7788
  Wire protocol: C
  Net options:
   timeout = 3.0 sec 
   connect-int = 5 sec 
   ping-int = 5 sec 
   max-epoch-size = 2048  (default)
   max-buffers = 2048  (default)
   sndbuf-size = 131070  (default)
   ko-count = 0  (default)
  Syncer options:
   rate = 30720 KB/sec 
   group = 0  (default)
   al-extents = 127  (default)
  --- End of example printout ---

   exit


Change (speed up) the sync rate and restore (TSP 5.1)
-------------------------------------------
If the system is an NSP 5.0 system, hardware wise, it is possible to speed up
the DRBD synching via the Gigabit link, which is connected between the IO
processors (en-1, eth3).
To accomplish this, perform the following:

  Make sure the Gigabit link between IO1 (eth3) and IO2 (eth3) is physically
  connected, and then verify that it is configured, as follows:
    On IO:
      /sbin/ifconfig -a  (Verify that inet addr for eth3 is configured)

    If not configured (info from uabnick) (not yet tested):
    From IO1:
      ifconfig eth3 down
      ifconfig eth3 192.11.0.1 netmask 255.255.255.0 up

    From IO2:
      ifconfig eth3 down
      ifconfig eth3 192.11.0.2 netmask 255.255.255.0 up

  Speed up the sync rate as follows:
    o Log in to the primary IO processor as root (or use "su -" if you are
      already logged in):
        ssh -X root@toXioY  (Adjust X to valid system and Y to valid IO,
                             or use IP address)
        Password: rootroot

    o Verify that the IO processor is primary:
        drbdsetup /dev/drbd0 state
        If the output is "Primary/Secondary", the IO processor is primary.
    o Show the sync rate (Syncer options: rate) (among other things):
        drbdsetup /dev/drbd0 show
    o Set the synchronization speed to 30MBytes/second (default value: 8M)
        drbdsetup /dev/drbd0 syncer -r 30M
    o Show the sync rate:
        drbdsetup /dev/drbd0 show
    o Wait until the synchronization is finished.
      You can monitor the synchronization by entering the following command
      repeatedly:
        cat /proc/drbd

    o When the sychronization is finished, restore the synchronization speed
      back to the default value 8MBytes/second:
        drbdsetup /dev/drbd0 syncer -r 8M
      DO NOT FORGET TO RESTORE!!!
    o Show the sync rate:
        drbdsetup /dev/drbd0 show
    o Exit the processor (or leave su mode):
        exit


Display a tree of processes executing on IO
-------------------------------------------
  pstree

  --- Start of example printout for primary IO (TSP 5.1, 2005-06-01) ---

init-+-cron
     |-drbd0_asender
     |-drbd0_receiver
     |-drbd0_worker
     |-events/0-+-aio/0
     |          |-kblockd/0
     |          |-khelper
     |          |-2*[pdflush]
     |          `-reiserfs/0
     |-in.tftpd
     |-inetd
     |-khpsbpkt
     |-khubd
     |-klogd
     |-kseriod
     |-ksoftirqd/0
     |-kswapd0
     |-lockd
     |-login---bash---tcsh
     |-mingetty
     |-monitord-+-DicosApplogClie
     |          |-DicosSyslogClie
     |          |-STSsw
     |          |-alarmgateway---alarmgateway---alarmgateway
     |          |-applogWatch---sleep
     |          |-crashcollector---sleep
     |          |-dhcpd
     |          |-ifmon
     |          |-named
     |          |-ntp-supervisor
     |          |-rpc.mountd
     |          |-sitedbserver
     |          `-tftpdumpd
     |-netdump-server
     |-8*[nfsd]
     |-portmap
     |-rpciod
     |-scsi_eh_0
     |-smartd
     |-sshd-+-sshd---sshd---bash
     |      |-sshd---sshd---bash---man---sh---less
     |      `-sshd---sshd---bash---pstree
     |-startpar
     |-syslogd
     `-9*[xterm---tcsh---telnet]
  --- End of example printout ---


  --- Start of example printout for secondary IO (TSP 5.1, 2005-06-01) ---
init-+-cron
     |-drbd0_asender
     |-drbd0_receiver
     |-drbd0_worker
     |-events/0-+-aio/0
     |          |-kblockd/0
     |          |-khelper
     |          |-2*[pdflush]
     |          `-reiserfs/0
     |-inetd
     |-khpsbpkt
     |-khubd
     |-klogd
     |-kseriod
     |-ksoftirqd/0
     |-kswapd0
     |-lockd
     |-login---bash---tcsh
     |-mingetty
     |-monitord-+-STSsw
     |          |-alarmgateway---alarmgateway---alarmgateway
     |          |-crashcollector---sleep
     |          |-ifmon
     |          |-ntp-supervisor
     |          `-tftpdumpd
     |-netdump-server
     |-portmap
     |-rpciod
     |-scsi_eh_0
     |-smartd
     |-sshd-+-sshd---sshd---bash
     |      `-sshd---sshd---bash---pstree
     |-startpar
     `-syslogd
  --- End of example printout ---


Check which processes that are being supervised by IO Monitor (TSP 5.1)
-------------------------------------------------------------
  cat /etc/monitord.conf

--- Start of example printout as of 2005-05-27, WP166 ---
#
# /etc/monitord.conf: I/O monitor configuration
#

# Format: <runlevel> <wait/respawn> <user> <command>

primary		wait		root 	/etc/monitor.d/wait/tipct1 start
primary		wait		root	/etc/monitor.d/wait/drbd0 start
primary		wait		root	/etc/monitor.d/wait/gem
primary         wait            root    /etc/monitor.d/wait/nfs start
primary		wait		root	/etc/monitor.d/wait/tftpd start
primary		respawn		root	/etc/monitor.d/respawn/mountd
primary		respawn		root	/etc/monitor.d/respawn/sitedb
primary		respawn		root	/etc/monitor.d/respawn/dhcpd
primary		respawn		root	/etc/monitor.d/respawn/named
primary		respawn		telorb	/etc/monitor.d/respawn/applog
primary		respawn		telorb	/etc/monitor.d/respawn/syslog
primary		respawn		telorb	/etc/monitor.d/respawn/applogwatch

secondary	wait		root	/etc/monitor.d/wait/tftpd stop
secondary       wait            root    /etc/monitor.d/wait/nfs stop
secondary	wait		root	/etc/monitor.d/wait/drbd0 stop
secondary	wait		root 	/etc/monitor.d/wait/tipct1 stop

all		respawn		root	/etc/monitor.d/respawn/alarm
all		respawn		root	/etc/monitor.d/respawn/ifmon
all		respawn		root	/etc/monitor.d/respawn/ntpmon
all		respawn		root	/etc/monitor.d/respawn/tftpdumpd
all		respawn		root	/etc/monitor.d/respawn/crash
all		respawn		telorb	/etc/monitor.d/respawn/console

# End of file
--- End of example printout ---

Legend:
  wait =      Started once, not supervised.
  respawn =   Supervised process, i.e. if it crashes, the IO Monitor will bring
              it up again.
  primary =   Process executing on primary IO.
  secondary = Process executing on secondary IO.
  all =       Process executing on both IOs.

Process name translation:
  alarm = alarmgateway
  ntpmon = ntp-supervisor
  crash = crashcollector
  console = consolelogs, STSsw

The applogwatch process supervises the applog.

If you want to edit this file, you have to edit it in both IOs.
Thereafter, you have to stop and start the IO Monitor in both IOs,
as described in the next section.


Stop and start the IO Monitor (TSP 5.1)
-----------------------------
On IO processor:
  su -                        (Important to be root!)
  Password: rootroot
  /etc/init.d/monitord stop
  /etc/init.d/monitord start
  exit

  Note: If you will stop the IO monitor on both IOs, wait for the printout
  "done", before stopping the IO monitor on the other IO, to avoid the risk
  of the IO monitor rebooting the IO.


Check which actions that have been performed by the IO Monitor (TSP 5.1)
--------------------------------------------------------------
On IO processor:
  su -
  Password: rootroot
  grep monitord /var/log/messages
  exit


Check the version of the operating system on an IO processor (TSP 5.1)
------------------------------------------------------------
On IO processor:
  cat /etc/version.IO_CXP


High avialability file system (HAFS)  (Old info?)
------------------------------------
cd /etc/ha.d/
less ha.cf
less haresources


Some directory contents on IOs (TSP 5.1)
------------------------------
ls -l /opt/telorb/bin/
total 512
-rwxr-xr-x  1 root root  49874 May 13 14:53 DicosApplogClient
-rwxr-xr-x  1 root root  33866 May 13 14:53 DicosSyslogClient
-rwxr-xr-x  1 root root  12950 May 13 14:53 STS_console
-rwxr-xr-x  1 root root  18268 May 13 14:53 STSsw
-rwxr-xr-x  1 root root    278 May 13 14:53 applogWatch
-rwxr-xr-x  1 root root   4934 May 13 14:53 crashcollector
-rwxr-xr-x  1 root root 239528 May 13 14:53 dataformatter
-rwxr-xr-x  1 root root   1298 May 13 14:53 eprtsetup
-rwxr-xr-x  1 root root   6084 May 13 14:53 eptee
-rwxr-xr-x  1 root root   1885 May 13 14:53 ping_all
-rwxr-xr-x  1 root root    138 May 13 14:53 rsitedb_updated
-rwxr-xr-x  1 root root   1011 May 13 14:53 sitedb_updated
-rwxr-xr-x  1 root root  13203 May 13 14:53 telorbBackups.sh
-rwxr-xr-x  1 root root  40388 May 13 14:53 tftpdumpd
-r-xr-xr-x  1 root root   4882 May 13 14:53 upgradeio
-rwxr-xr-x  1 root root  52280 May 13 14:53 win

ls -l /opt/telorb/axe/tsp/
total 3982
drwxr-xr-x  7 telorb telorb     168 May 14 12:07 NM
drwxr-xr-x  2 telorb telorb     744 May 17 16:46 applog
drwxr-xr-x  3 telorb telorb    1688 May 18 10:53 consolelogs
drwxr-xr-x  7 telorb telorb     928 May 17 17:23 crashcollector
drwxr-xr-x  2 telorb telorb      48 May 13 14:54 log
drwxr-xr-x  3 root   root        72 May 14 12:04 ss7
-rw-r--r--  1 telorb telorb 1966649 May 18 10:51 syslog
-rw-r--r--  1 telorb telorb 2097157 May 17 09:32 syslog.bak


ifconfig on to20io1 (Secondary) (TSP 5.1)
-------------------------------
/sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:87  
          inet addr:172.16.8.129  Bcast:172.16.15.255  Mask:255.255.248.0
          inet6 addr: fe80::220:ceff:fec9:8187/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:66043 errors:0 dropped:0 overruns:0 frame:0
          TX packets:65724 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8184919 (7.8 Mb)  TX bytes:8089731 (7.7 Mb)
          Base address:0xd480 Memory:fe9c0000-fe9e0000 

eth1      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:86  
          inet addr:172.16.0.129  Bcast:172.16.7.255  Mask:255.255.248.0
          inet6 addr: fe80::220:ceff:fec9:8186/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67005 errors:0 dropped:0 overruns:0 frame:0
          TX packets:66790 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8186672 (7.8 Mb)  TX bytes:8166748 (7.7 Mb)
          Base address:0xd400 Memory:fe9a0000-fe9c0000 

eth2      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:84  
          inet addr:134.138.187.89  Bcast:134.138.191.255  Mask:255.255.248.0
          inet6 addr: fec0::1140:220:ceff:fec9:8184/64 Scope:Site
          inet6 addr: fe80::220:ceff:fec9:8184/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6201 errors:0 dropped:0 overruns:0 frame:0
          TX packets:546 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:618845 (604.3 Kb)  TX bytes:88998 (86.9 Kb)
          Base address:0xd000 Memory:fe960000-fe980000 

eth3      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:85  
          inet addr:192.11.0.1  Bcast:192.11.0.255  Mask:255.255.255.0
          inet6 addr: fe80::220:ceff:fec9:8185/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:96850 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34734 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:105553314 (100.6 Mb)  TX bytes:10245826 (9.7 Mb)
          Base address:0xd080 Memory:fe980000-fe9a0000 

gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-35-00-00-00-00-00-00-00-00-00-00-00  
          NOARP  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:156 errors:0 dropped:0 overruns:0 frame:0
          TX packets:156 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:10192 (9.9 Kb)  TX bytes:10192 (9.9 Kb)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

tipct0    Link encap:Ethernet  HWaddr 00:01:00:10:65:30  
          inet addr:172.16.32.129  Mask:255.255.248.0
          inet6 addr: fe80::201:ff:fe10:6530/64 Scope:Link
          UP RUNNING NOARP  MTU:10000  Metric:1
          RX packets:24964 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20049 errors:3 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:64 
          RX bytes:94882258 (90.4 Mb)  TX bytes:6215282 (5.9 Mb)

tipct1    Link encap:Ethernet  HWaddr 00:01:00:10:65:31  
          NOARP  MTU:10000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:1 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:64 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

tunl0     Link encap:IPIP Tunnel  HWaddr   
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


ifconfig on to20io2 (Primary) (TSP 5.1)
-----------------------------
/sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:7F  
          inet addr:172.16.9.1  Bcast:172.16.15.255  Mask:255.255.248.0
          inet6 addr: fe80::220:ceff:fec9:817f/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1941154 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1283385 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:983048402 (937.5 Mb)  TX bytes:155999364 (148.7 Mb)
          Base address:0xd480 Memory:fe9c0000-fe9e0000 

eth1      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:7E  
          inet addr:172.16.1.1  Bcast:172.16.7.255  Mask:255.255.248.0
          inet6 addr: fe80::220:ceff:fec9:817e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1341673 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1339820 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:171750181 (163.7 Mb)  TX bytes:172361159 (164.3 Mb)
          Base address:0xd400 Memory:fe9a0000-fe9c0000 

eth2      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:7C  
          inet addr:134.138.187.90  Bcast:134.138.191.255  Mask:255.255.248.0
          inet6 addr: fec0::1140:220:ceff:fec9:817c/64 Scope:Site
          inet6 addr: fe80::220:ceff:fec9:817c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:108938 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2426 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10921485 (10.4 Mb)  TX bytes:599471 (585.4 Kb)
          Base address:0xd000 Memory:fe960000-fe980000 

eth3      Link encap:Ethernet  HWaddr 00:20:CE:C9:81:7D  
          inet addr:192.11.0.2  Bcast:192.11.0.255  Mask:255.255.255.0
          inet6 addr: fe80::220:ceff:fec9:817d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2041969 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1406394 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2015017534 (1921.6 Mb)  TX bytes:1113655837 (1062.0 Mb)
          Base address:0xd080 Memory:fe980000-fe9a0000 

gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-64-00-00-00-00-00-00-00-00-00-00-00  
          NOARP  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:21626 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21626 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:47700008 (45.4 Mb)  TX bytes:47700008 (45.4 Mb)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

tipct0    Link encap:Ethernet  HWaddr 00:01:00:10:66:30  
          inet addr:172.16.33.1  Mask:255.255.248.0
          inet6 addr: fe80::201:ff:fe10:6630/64 Scope:Link
          UP RUNNING NOARP  MTU:10000  Metric:1
          RX packets:641267 errors:0 dropped:0 overruns:0 frame:0
          TX packets:590509 errors:26 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:64 
          RX bytes:1788329866 (1705.4 Mb)  TX bytes:965028589 (920.3 Mb)

tipct1    Link encap:Ethernet  HWaddr 00:01:00:10:66:31  
          inet addr:172.16.39.254  Mask:255.255.0.0
          inet6 addr: fe80::201:ff:fe10:6631/64 Scope:Link
          UP RUNNING NOARP  MTU:10000  Metric:1
          RX packets:53789 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:4 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:64 
          RX bytes:8613715 (8.2 Mb)  TX bytes:0 (0.0 b)

tunl0     Link encap:IPIP Tunnel  HWaddr   
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


mount on to20io1 (Secondary) (TSP 5.1)
----------------------------
mount
/dev/sda7 on / type reiserfs (rw)
proc on /proc type proc (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda6 on /boot type reiserfs (rw)
/dev/sda8 on /var type reiserfs (rw)
172.16.39.254:/opt/mirror on /opt/telorb/axe type nfs (rw,udp,rsize=8192,wsize=8192,timeo=14,hard,intr,retry=3,addr=172.16.39.254)


mount on to20io2 (Primary) (TSP 5.1)
--------------------------
mount
/dev/sda7 on / type reiserfs (rw)
proc on /proc type proc (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda6 on /boot type reiserfs (rw)
/dev/sda8 on /var type reiserfs (rw)
172.16.39.254:/opt/mirror on /opt/telorb/axe type nfs (rw,udp,rsize=8192,wsize=8192,timeo=14,hard,intr,retry=3,addr=172.16.39.254)
/dev/drbd0 on /opt/mirror type reiserfs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)


VIP trace
---------
E.g. on IO processor:
  /usr/sbin/traceroute <external_VIP_address>    (E.g. 172.30.14.14)
  netstat -rn

E.g. on Linux TP:
  tcpdump -n -i eth2 proto 89


Printout example from a Primary IO processor when the synching is in progress
-----------------------------------------------------------------------------
Taken from TSP 5.0:

version: 0.6.3 (api:61/proto:62)

0: cs:SyncingAll st:Primary/Secondary ns:4651356 nr:0 dw:57804 dr:4790873 pe:74 ua:0
	[==================>.] sync'ed: 93.0% (346/4888)M
	finish: 0:51min speed: 6,903 (6,541) K/sec


Printout example from a Primary IO processor when the synching is finished
--------------------------------------------------------------------------
Taken from TSP 5.1:

version: 0.7.6 (api:77/proto:74)
SVN Revision: 1663 build by phil@mescal, 2004-11-29 13:47:11
 0: cs:Connected st:Primary/Secondary ld:Consistent
    ns:96940 nr:1630896 dw:1731324 dr:17560 al:4 bm:180 lo:0 pe:0 ua:0 ap:0
 1: cs:Unconfigured


Printout example from a Secondary IO processor when the synching is in progress
-------------------------------------------------------------------------------
Taken from TSP 5.0:

version: 0.6.3 (api:61/proto:62)

0: cs:SyncingAll st:Secondary/Primary ns:0 nr:4636724 dw:4636724 dr:0 pe:0 ua:122
	[==================>.] sync'ed: 92.7% (360/4888)M
	finish: 0:54min speed: 6,820 (6,539) K/sec


Printout example from a Secondary IO processor when the synching is finished
----------------------------------------------------------------------------
Taken from TSP 5.1:

version: 0.7.6 (api:77/proto:74)
SVN Revision: 1663 build by phil@mescal, 2004-11-29 13:47:11
 0: cs:Connected st:Secondary/Primary ld:Consistent
    ns:0 nr:92184 dw:92184 dr:0 al:0 bm:19 lo:0 pe:0 ua:0 ap:0


Legend (TSP 5.1)
------
WFConnection = Waiting For Connection
Consistent   = Can become primary


Get a Secondary StandAlone IO processor going (TSP 5.1)
---------------------------------------------
Go from the StandAlone state to WFConnection state:
  drbdadm connect all
    (drbdadm = Administration tool for DRBD)


Start a full sync (info valid only for TSP 5.0! Not valid for later releases!!!)
-----------------
On IO (primary or secondary?):
  su -
  Password: rootroot
  drbdsetup /dev/nb0 replicate
  exit
    (drbdsetup = Setup tool for DRBD)


Check all processes that are executing on the IO processor
----------------------------------------------------------
ps -auxww


Script "check_sync_time" for checking sync time
-----------------------------------------------
Place the script on any of the IO processors below /home/telorb/.

--- Script start --- 
#!/bin/sh

flag_1=0
flag_2=0
flag_3=0
START_TIME=
SYNC=
SPEED=
file=/proc/drbd

while true;do
  
   cat $file | grep SyncingAll > /dev/null

      if [ $? = 0 ];then
         flag_1=1
         if [ $flag_2 = 0 ];then
            START_TIME=`date '+START_TIME:%H:%M:%S'`
            SYNC=`awk '/sync/ {print "\t" $3}' /proc/drbd`
            SPEED=`awk '/speed/ {print "\t" $4,$5,$6}' /proc/drbd`
            echo $START_TIME 
            echo "Sync'ed:$SYNC"
            echo "speed: $SPEED"
            flag_2=1
         else 
            SYNC=`awk '/sync/ {print "\t" $3}' /proc/drbd`
            SPEED=`awk '/speed/ {print "\t\t" $4,$5,$6}' /proc/drbd`
            echo "********"
            echo "Sync'ed:$SYNC"
            echo "speed: $SPEED"
         fi
      else
         if [ $flag_1 = 1 ];then
            echo $START_TIME
            date '+FINISH_TIME:%H:%M:%S' 
            exit
          else
              if [ $flag_3 = 0 ];then
                 echo "FullSync has not started ..."
                 flag_3=1
               fi

         fi
      fi

   sleep 2
done
--- Script end ---

--- Example of script printout start ---
Sync'ed:	33.4%
speed: 		532 (495) K/sec
********
Sync'ed:	33.4%
speed: 		1,616 (495) K/sec
********
Sync'ed:	33.5%
speed: 		1,288 (495) K/sec
********
Sync'ed:	33.5%
speed: 		914 (495) K/sec
********
--- Example of script printout end ---

(Updated: 2005-05-17)

IO upgrade prerequisites
------------------------
An IO upgrade package consists of the IDP IO_CXP in a packed format, i.e. a
tgz file, e.g. CXP9010596_1_R50FY01-IO.tgz.

- To test the IO upgrade functionality, you need an IO upgrade package.
  If you do not have an IO upgrade package, you can just use the same file as is
  currently being used in the system, since the upgrade script does not have a
  version check (i.e. it is possible to upgrade to the same version).
  This file, i.e. CXP9010596_1_<version>-IO.tgz, is located at
  /opt/telorb/axe/runtimes/<...Runtime>/system/unix/ on both IO processors.

  If you want to verify that the actual IO_CXP version is changed as a result
  of an IO upgrade, you can change the current IO_CXP version before performing
  the upgrade as follows:
    On both IO processors, change the current IO_CXP version to e.g. P1A01T:
      su -   (Enter root mode)
      Password: rootroot
      cat /etc/version.IO_CXP
      vi /etc/version.IO_CXP
        Change the version from e.g. R1K02 to e.g. P1A01T.
        Save and exit.
      exit   (Exit root mode)
      cat /etc/version.IO_CXP
        Example of printout: CXP9010596/1 P1A01T
    Thereafter, when copying the upgrade package as described in the next step,
    copy it from directory
    /opt/telorb/axe/runtimes/<...Runtime>/system/unix/, e.g.:
      cp /opt/telorb/axe/runtimes/<...Runtime>/system/unix/CXP9010596_1_<version>-IO.tgz /home/telorb/
    Repeat for the other IO processor.


IO upgrade procedure
--------------------
- Copy the IO upgrade package to both IO processors, if not already done in the
  previous step (in this example, the upgrade package is copied to the directory
  /home/telorb/ on to20io1):
    scp /ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV14/WP139/cwos-WP139-Runtime/system/unix/CXP9010596_1_R50FY01-IO.tgz telorb@to20io1:
                                               (Adjust the path and CXP version)

    scp /ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV14/WP139/cwos-WP139-Runtime/system/unix/CXP9010596_1_R50FY01-IO.tgz telorb@to20io2:
                                               (Adjust the path and CXP version)

- Log in to one of the IO processors:
    ssh -X telorb@toXio1

- Check which IO processor is secondary:
    cat /proc/drbd

- If not already logged in to the secondary IO processor, log out and log in to
  the secondary IO processor:
    ssh -X telorb@toXio2

- Verify that no disk synchronization is in progress:
    cat /proc/drbd

- If synchronization is in progress, wait for it to complete before continuing
  with the next step.

- Enter root mode:
    su -

- Upgrade the IO processor:
    Valid for LSV166 and onwards:
      /opt/telorb/bin/upgradeio /home/telorb/CXP9010596_1_R50FY01-IO.tgz

    Valid for LSV140 and backwards:
      /opt/telorb/bin/upgradeio --cxp=<path_to_IO_upgrade_package_directory>

To be continued... (See the official operating instruction (as you should have
done in the first place).)

(Updated: 2005-02-01)

To reduce the long backup times in TSP 5.1 LSV4/LSV5, change the NFS server 
export mode from "sync" to "async" and also add the option "no_subtree_check".

To change these options, perform the following steps on both I/O machines:

1. su (become root)
2. cd /etc/init.d
3. vi exportsConfig

Write 'async' instead of 'sync' and also add ',no_subtree_check' on the 
EXPORTS line. So the EXPORTS line looks like this:

  EXPORTS="$EXPORTS ${net}/${netmask}(rw,async,no_subtree_check,root_squash,anonuid=$telorb_uid,anongid=$telorb_gid) "

4. Reboot the I/O machines one by one or perform a ZoneReload.


NOTE: Running the NFS server in "async" mode is not a permanent solution 
to this problem since it can not guarantee data consistency in case of I/O
failover.
(Source: E-mail from Per Lidén, 2004-12-20)

(Updated: 2004-06-09)

If the time is not correct in the system, i.e. in the processors, edit the file
/etc/ntp.conf on both IO processors, as follows:
  su
  psw
  emacs /etc/ntp.conf& 

  Change:
    ## server xx.xx.xx.xx		# IP address of server
  to:
    server 134.138.226.13		# IP address of server

  exit

  To activate the new NTP server IP address, reload all processors one by one
  (or perform a zone reload ???).

(Updated: 2004-06-09)

Get Linux version on e.g. IOs:
  uname -r
    2.4.19-R2A26-4GB
  uname -a
    Linux Proc_m1_s1 2.4.19-R2A26-4GB #1 Fri Mar 26 18:27:28 CET 2004 i686 unknown

(Updated: 2005-01-31)

On e.g. local Linux PC without any sourcing (cannot use this on UNIX, Linux
required):

  Execution:
  /ipims_dicos/BS2/tbWP080/tsp_deliverables/AutoTest_IDP/included/LM_D345-AutoTargetTest/tt -s to3 -n -D -c 2 -t /ipims_dicos/BS2/tbWP0xx -H NSP4.x_Maxi -v 172.30.14.3
     (tbWP080 may have to be adjusted to get the latest version of the Auto
      Target Tester) (Adjust tbWP0xx to valid work package)

  Example:
  /ipims_dicos/BS2/tbWP080/tsp_deliverables/AutoTest_IDP/included/LM_D345-AutoTargetTest/tt -s to14 -n -c 1 -t /ipims_dicos/BS2/tbWP026/ -H NSP4.x_Maxi -v 172.30.14.14

  Get help file:
  /ipims_dicos/BS2/tbWP080/tsp_deliverables/AutoTest_IDP/included/LM_D345-AutoTargetTest/tt -h
     (tbWP080 may have to be adjusted to get the latest version of the Auto
      Target Tester)
  --- Help text start ---
Help text:
Syntax tt [-h] [-l #] -t <testbed> -s <system> [-d <distribution>] -e <examples> [-c #] [-a] [-p <path>] -w <path>
       A tool to test a tsp system automatically on target


       All results will end up under ~/public_html/...<timestamp>
       if -n is not chosen loadingGroup01_1 and upgradePackages will
       be copied to target.


Switches:
   -h        print this text
   -a        Run the automated testcases with CAT
   -c #      The configuration to be tested 1=dicos max, 
                                            2=mixed,
                                            3=linux only. 
             Default=2.
   -d <path> The supplied path is the distribution to be tested.
   -D        Use the debug kernels, default is no debug kernels.
   -f <path> Full path to custom testCaseFile.
   -H <hw>   Hardware configuration. eg NSP4.x_Micro
   -l #      Debug printout level (10=verbose). Default=0.
   -n        Dryrun, don NOT update IOs
   -p <path> epconfig set extra MIs recursively in this path.
   -s <system> The system name, eg to1
   -v <addres> The system vip address, e.g. 172.30.14.1.
   -t <path> The supplied path is the testbed to be tested.
   -z #      The zone id. Default=1.
  --- Help text stop ---

User's guide: 14/1553-APR 901 578/1 Uen

For further info, contact Magnus Engberg.

(Updated: 2004-06-16)

Log in to processor using the VIP address:
  telnet 134.138.71.14 8110                  (to14)
  qtil
  pts

From IO:
  telnet localhost 8110
    -or-
  telnet Proc_m2_s1 8110

Log in to a Linux processor (including FS) from IO
--------------------------------------------------
ssh Proc_m0_s21  -or-  ssh -X telorb@Proc_m0_s1
yes
Password: telorb
Terminal type? vt100

/sbin/ifconfig -a

(Updated: 2004-06-09)

Check which cluster control processor that is CM master
-------------------------------------------------------

From IO:
  telnet localhost 8110
    -or-
  telnet Proc_m2_s1 8110   (Log in to any processor)

  cd sws/cm/
  cat state

    CM master located on processor: Proc_m2_s1 (1.21)
    Current CM state is: 4 (see DswcmConfigurationManagerControl.hh)
    Software version is: backups/Traffic

    CMAD (see DswcmCmCmaInterface.hh):
    Waiting for message(s): 16 17

    Other (outstanding) asynchronous messages  (see
    DswcmConfigurationManagerControl.hh):

Check each processor's OpState/LoaderState
------------------------------------------
cat psm

PSM states (see DswcmDcpListItem.hh): 
  DCP 1.15:	 OpState: 3	 LoaderState: 2	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.1:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.2:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.3:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.4:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.5:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.6:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.7:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.8:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.9:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.10:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.11:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.12:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.13:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2 
  DCP 1.14:	 OpState: 2	 LoaderState: 3	 scheduledForHwReconfiguration: 0	 Mngmt-state: 2

    -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    OpState and LoaderState explanations for TSP 5.0
    ------------------------------------------------
    OpState
      {
        Configured,
        Disabled,
        NotConnected,
        Connected,
        RestartOrdered,
        ReloadOrdered,
        Restarting,
        Reloading,
        NumberOfStates
      };
  
    LoaderState
      {
        NonLoader,
        StdbyPlgLoader,
        PrimPlgLoader,
        SelfLoader
      };

    (Source:
     more /ipims_dicos/BS2/tbAD15/DICOS_SA/SoftwareSupport_SE/
       ConfigurationManager_OB/ConfigurationManagerControl_OU/src/
       DswcmDcpListItem.hh)
    -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

quit

Bonus info:
  cd ../..
  cd CLI
  cd Backups/
  list
    --- Backups ---
    Initial
    Populated
    (A)Traffic
    -----------------
    ###### SCHEDULER ######
    Scheduler is: Enabled
    --- Periodic Scheduling ---
    No periodic scheduling done
    Number of periodic backups kept:3
    -------------------------
    --- Scheduled Fixeds: ---
    Number of fixed backups kept:3
    -------------------------
    No backups/remote synchs scheduled

(Updated: 2004-09-15)

Alternative 1
-------------
On any of the IO processors:
  cd /opt/telorb/axe/tsp/consolelogs
  grep 'CMA star' Proc*

Example of printout:
-----> CMA started on processor: Proc_m0_s11 [1.2]
Proc_m0_s13.b:-----> CMA started on processor: Proc_m0_s13 [1.3]
Proc_m0_s15.b:-----> CMA started on processor: Proc_m0_s15 [1.4]
Proc_m0_s17.b:-----> CMA started on processor: Proc_m0_s17 [1.5]
Proc_m0_s19.b:-----> CMA started on processor: Proc_m0_s19 [1.6]
-----> CMA started on processor: Proc_m0_s21 [1.7]
-----> CMA started on processor: Proc_m0_s23 [1.8]
Proc_m1_s1.b:-----> CMA started on processor: Proc_m1_s1 [1.9]
-----> CMA started on processor: Proc_m1_s11 [1.11]
Proc_m1_s13.b:-----> CMA started on processor: Proc_m1_s13 [1.12]
Proc_m1_s15.b:-----> CMA started on processor: Proc_m1_s15 [1.13]
Proc_m1_s17.b:-----> CMA started on processor: Proc_m1_s17 [1.14]
-----> CMA started on processor: Proc_m1_s23 [1.15]
Proc_m2_s1:-----> CMA started on processor: Proc_m2_s1 [1.16]
Proc_m2_s1.b:-----> CMA started on processor: Proc_m2_s1 [1.16]
-----> CMA started on processor: Proc_m3_s13 [1.19]
-----> CMA started on processor: Proc_m3_s19 [1.20]
-----> CMA started on processor: Proc_m3_s21 [1.21]
Proc_m3_s7.b:-----> CMA started on processor: Proc_m3_s7 [1.17]
-----> CMA started on processor: Proc_m3_s9 [1.18]
Proc_m4_s11.b:-----> CMA started on processor: Proc_m4_s11 [1.22]
Proc_m4_s15.b:-----> CMA started on processor: Proc_m4_s15 [1.23]
-----> CMA started on processor: Proc_m4_s17 [1.24]
-----> CMA started on processor: Proc_m4_s21 [1.25]
-----> CMA started on processor: Proc_m4_s23 [1.26] 


Alternative 2
-------------
telnet 172.16.0.9 8110
  cd sws/
  cat processors

Example of printout:
  1.3  <-->  Proc_m0_s9
  1.1  <-->  Proc_m0_s1
  1.2  <-->  Proc_m0_s5
  1.4  <-->  Proc_m0_s11
  1.5  <-->  Proc_m0_s13
  1.6  <-->  Proc_m0_s15
  1.7  <-->  Proc_m0_s17
  1.8  <-->  Proc_m0_s19
  1.9  <-->  Proc_m0_s21
  1.10  <-->  Proc_m0_s23
  1.11  <-->  Proc_m1_s1
  1.12  <-->  Proc_m1_s5
  1.13  <-->  Proc_m1_s9
  1.14  <-->  Proc_m1_s11
  1.15  <-->  Proc_m1_s13
  1.16  <-->  Proc_m1_s15
  1.17  <-->  Proc_m1_s17
  1.18  <-->  Proc_m1_s19
  1.19  <-->  Proc_m1_s21
  1.20  <-->  Proc_m1_s23
  1.21  <-->  Proc_m2_s1
  1.22  <-->  Proc_m3_s1
  1.23  <-->  Proc_m3_s5
  1.24  <-->  Proc_m3_s7
  1.25  <-->  Proc_m3_s9
  1.26  <-->  Proc_m3_s11
  1.27  <-->  Proc_m3_s13
  1.28  <-->  Proc_m3_s15
  1.29  <-->  Proc_m3_s17
  1.30  <-->  Proc_m3_s19
  1.31  <-->  Proc_m3_s21 

(Source: E-mails from Peder Magnusson, 2004-03-17 and 2004-09-14)

(Updated: 2004-06-09)

Change syslog (or applog) level to e.g. 7 (max output):
  ssh telorb@to14io2    (Log in to processor, e.g. IO2)
  Password: telorb
  /var/opt/telorb/bin/syslogserver -sl       (Print the syslog level,
                                              -al = print the applog level)
  /var/opt/telorb/bin/syslogserver -sL 7 -l  (Set syslog level=5, print and
                                              quit. To set applog, use "a"
                                              instead of "s")
  /var/opt/telorb/bin/syslogserver -h        (Get syslog help)

Repeat for the rest of the processors in the cluster, if necessary.
Note that when reloading a processor, the default syslog/applog setting (5)
will be restored.

(Updated: 2005-01-26)

IPv4
====
Contents of the vip.epct file
-----------------------------
INITIAL DATA
SocketUserDistributionCfg_1040 = "IpV4:IPPROTO_TCP:5987:roundRobinDistributor"
SocketUserDistributionCfg_1050 = "IpV4:IPPROTO_TCP:5988:roundRobinDistributor"
ENDDATA

ENVIRONMENT DATA

//VIP traffic

  VIP_TRAFFIC_RECEIVER_CONFIGPORT = "5987"
  VIP_TRAFFIC_RECEIVER_TRAFFICPORT = "5988"
  VIP_TRAFFIC_RECEIVER_STRESS = "0"
  VIP_TRAFFIC_RECEIVER_DEBUG = "0"

ENDDATA

Also the following?
  VipOspf_AreaID = "10.0.0.0"
  VipOspf_HelloInterval = 10
  VipOspf_RouterDeadInterval = 40


In a shell on e.g. local Linuc PC:

- Source the valid testbed, e.g.:
    tcsh
    source /ipims_dicos/BS2/tbWP026/tsp_deliverables/Setup.csh

- Check where to start the VIP traffic generator from (the result path should
  be used when starting the VIP traffic):
    epgetpath LM/VIP101

- Start VIP traffic by entering the following command, after adjusting the path
  and VIP address to the system (172.30.14.xx):
    /ipims_dicos/ipims_dicos10/dists/TSP5.1/LSV7/tsp-LSV7-test/system/TelORB/CXP9011112_1_R50C03-VIPtrafficgenerator/included/LM_VIP101-VIPtrafficgenerator/bin/VIPtrafficgenerator.LM_VIP101.R50C01.i486-Redhat-6.0 172.30.14.xx 5987 5988

    (Old:
/home/dicosarc10/archive/LSV1/cwos-LSVtsp51base-test/system/TelORB/IDP_VIP101_R1A02-VIPtrafficgenerator/included/LM_VIP101-VIPtrafficgenerator/bin/VIPtrafficgenerator.LM_VIP101.R2A02.i486-Redhat-6.0 172.30.14.xx 5987 5988)

Set up the external VIP traffic scenario by using the TelORB Manager as follows:
- Populate.
- Select "External VIP traffic".
- Select "Dicos traffic" or "Linux traffic".        (Both kinds can be executing
                                                     simultaneously, e.g.
                                                     500 calls/sec each)
- Select "RUN" or "JRUN".                           (Both kinds can be executing
                                                     simultaneously, e.g.
                                                     500 calls/sec each)

    If you receive the message "Check your input values!", you have most
    probably forgotten to start the external VIP traffic or the total
    percentage value for the traffic type selections exceeds 100%.

- Verify that you get traffic execution statistics in the same window as the
  VIP traffic was started (the previously set "Print interval" decides how
  often the printouts will occur).
 
Example of traffic setup:

  Dicos traffic:
      External VIP traffic:
			C++:  CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 500              (calls/sec)
                              Ranging from: 0    Ranging to: 2000000

			Java: CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 500              (calls/sec)
                              Ranging from: 0    Ranging to: 2000000

  Linux traffic:
      External VIP traffic:
			C++:  -  (Add info)
			Java: -  (Add info)

=========================================================

IPv4 and IPv6
=============
Example of E10cwos_initial.epct file located at /var/opt/tsp/epct/ on IO (valid
for system to11, mixed configuration) (Dicos (Proc_m0_s21) and Linux
(Proc_m0_s15)(no pool adjustments are necessary):

// CW/OS initial data epct file.
// Strictly for backwards compatibility.
//
// Autogenerated 2004-10-15 11:26 GMT+00:00.
// Manually modified by Michel Sundin, 2004-11-11.

INITIAL DATA
BOOT_buffer_size = 16000000
LMD_buffer_size = 8000000
LMR_buffer_size = 8000000
JAVA_CAPSULE_HEAP = 64
JAVA_HEAP = 30
JAVA_PERM_HEAP = 16
DswcmMaxTimeForReload = 20

// IPv4 VIP Commands (Dicos and Linux processors can be used)
i4ddCommand_1000 = "ddconfig i4dd0 Proc_m0_s15-eth2-192.168.76.1 Proc_m0_s21-fxp0-192.168.77.2"
i4ddCommand_1010 = "ifconfig i4dd0 inet 172.30.14.11"
i4ddCommand_1020 = "route add default -interface i4dd0"
DorbExternalIIOPHostName = "172.30.14.11"
i4ddCommand_1030 = "ddconfig i4dd1"
i4ddCommand_1040 = "ifconfig i4dd1 inet 192.168.100.64"
SocketUserDistributionCfg_1000 = "IpV4:IPPROTO_TCP:2809:roundRobinDistributor"
SocketUserDistributionCfg_1010 = "IpV4:IPPROTO_TCP:7111:roundRobinDistributor"
SocketUserDistributionCfg_1020 = "IpV4:IPPROTO_TCP:10000:roundRobinDistributor"
SocketUserDistributionCfg_1030 = "IpV4:IPPROTO_TCP:30630:roundRobinDistributor"
SocketUserDistributionCfg_1040 = "IpV4:IPPROTO_TCP:5987:roundRobinDistributor"
SocketUserDistributionCfg_1050 = "IpV4:IPPROTO_TCP:5988:roundRobinDistributor"

VipOspf_AreaID = "10.0.0.0"
VipOspf_HelloInterval = 10
VipOspf_RouterDeadInterval = 40

// IPv6 VIP Commands (Only Linux processors can be used)
i4ddCommand_1100 = "ddconfig i6dd0 Proc_m0_s15-eth2-fe80::20c:ceff:fe6c:2a10"
i4ddCommand_1110 = "ifconfig i6dd0 inet6 fec0:0:0:10::11"
i4ddCommand_1120 = "route add -inet6 default -interface i6dd0"
SocketUserDistributionCfg_1100 = "IpV6:IPPROTO_TCP:5989:roundRobinDistributor"
SocketUserDistributionCfg_1110 = "IpV6:IPPROTO_TCP:5990:roundRobinDistributor"

VipOspfV3_AreaID = "10.10.10.10"
VipOspfV3_HelloInterval = 10
VipOspfV3_RouterDeadInterval = 40

ENDDATA

ENVIRONMENT DATA
ENDDATA


-- Old info below! To be removed when the above setup has been verified! --
// CW/OS initial data epct file.
// Strictly for backwards compatibility.
//
// Autogenerated 2004-09-17 13:07 GMT+00:00.
// Manually modified by Michel Sundin, 2004-09-20.

INITIAL DATA
BOOT_buffer_size = 16000000
LMD_buffer_size = 8000000
LMR_buffer_size = 8000000
JAVA_CAPSULE_HEAP = 64
JAVA_HEAP = 30
JAVA_PERM_HEAP = 16
DswcmMaxTimeForReload = 20

// TelORB VIP IPv4 commands (Dicos and Linux processors can be used)
i4ddCommand_1000 = "ddconfig i4dd0 Proc_m0_s17-fxp0-192.168.77.2 Proc_m0_s19-eth2-192.168.76.1 Proc_m0_s15-fxp1-192.168.76.1 Proc_m0_s21-eth3-192.168.77.2"
i4ddCommand_1010 = "ifconfig i4dd0 inet 172.30.14.11"
i4ddCommand_1020 = "route add default -interface i4dd0"
DorbExternalIIOPHostName = "172.30.14.11"
i4ddCommand_1030 = "ddconfig i4dd1"
i4ddCommand_1040 = "ifconfig i4dd1 inet 192.168.100.64"
SocketUserDistributionCfg_1000 = "IpV4:IPPROTO_TCP:2809:roundRobinDistributor"
SocketUserDistributionCfg_1010 = "IpV4:IPPROTO_TCP:7111:roundRobinDistributor"
SocketUserDistributionCfg_1020 = "IpV4:IPPROTO_TCP:10000:roundRobinDistributor"
SocketUserDistributionCfg_1030 = "IpV4:IPPROTO_TCP:30630:roundRobinDistributor"
SocketUserDistributionCfg_1040 = "IpV4:IPPROTO_TCP:5987:roundRobinDistributor"
SocketUserDistributionCfg_1050 = "IpV4:IPPROTO_TCP:5988:roundRobinDistributor"

VipOspf_AreaID = "10.0.0.0"
VipOspf_HelloInterval = 10
VipOspf_RouterDeadInterval = 40

// TelORB VIP IPv6 commands (Only Linux processors can be used)
i4ddCommand_1100 = "ddconfig i6dd0 Proc_m0_s19-eth2-fe80::20c:ceff:fe6c:2a10 Proc_m0_s21-eth3-fe80::20c:85ff:fe1a:9070"
i4ddCommand_1110 = "ifconfig i6dd0 inet6 fec0:0:0:10::11"
i4ddCommand_1120 = "route add -inet6 default -interface i6dd0"
SocketUserDistributionCfg_1100 = "IpV6:IPPROTO_TCP:5989:roundRobinDistributor"
SocketUserDistributionCfg_1110 = "IpV6:IPPROTO_TCP:5990:roundRobinDistributor"

VipOspfV3_AreaID = "10.10.10.10"
VipOspfV3_HelloInterval = 10
VipOspfV3_RouterDeadInterval = 40

ENDDATA

ENVIRONMENT DATA
ENDDATA
-- Old info above! To be removed when the new setup has been verified! --

(For further epct file examples, see further down.)

Port explanations
-----------------
SocketUserDistributionCfg_0 = "0x800:6:6497:roundRobinDistributor"           // JIM - Do not expose in firewall (NM)
SocketUserDistributionCfg_1 = "0x800:17:5630:roundRobinDistributor"          // JIM SNMP - Expose in firewall (NM)
SocketUserDistributionCfg_2 = "0x800:6:3306:roundRobinDistributor"           // MySQL - Expose in firewall  (NM)
SocketUserDistributionCfg_3 = "0x800:6:443:stickyIpDistributor"	             // HTTPS - Expose in firewall (NM)
SocketUserDistributionCfg_4 = "0x800:6:7111:roundRobinDistributor"           // CosNaming - Expose in firewall (CW/OS)
SocketUserDistributionCfg_5 = "0x800:6:389:roundRobinDistributor"            // LDAP (ECN) - Expose in firewall (NM)
SocketUserDistributionCfg_6 = "0x800:17:161:roundRobinDistributor"           // SNMP - Expose in firewall (NM)
SocketUserDistributionCfg_7 = "0x800:6:9229:roundRobinDistributor"           // Alex (omnidaemon) - Expose in firewall (NM)
SocketUserDistributionCfg_8 = "0x800:6:30330:roundRobinDistributor"          // CORBA - Do not expose in firewall (?)
SocketUserDistributionCfg_9 = "0x800:6:30630:roundRobinDistributor"          // CORBA - Expose in firewall (CW/OS)
SocketUserDistributionCfg_10 = "0x800:6:35850:roundRobinDistributor"         // ECN - Expose in firewall (NM)
SocketUserDistributionCfg_11 = "0x800:6:7423:roundRobinDistributor"          // LDAP - Expose in firewall (NM)
SocketUserDistributionCfg_12 = "0x800:6:7323:clusterRoundRobinDistributor"   // LDAP (NM)

SocketUserDistributionCfg_13 = "0x800:6:10000:roundRobinDistributor"         // LoadViewer (bin/win) (CW/OS)

E.g. port 10000 is used for the LoadViewer (bin/win)

-- -- --

The important changes in the E10cwos_initial.epct file are as follows.

IPv4 section:
- In the i4ddCommand_1000 line, change colons (:) to dashes (-), i.e.
  change
  ":eth0:", ":eth1:", ":fxp0:" and ":fxp1:"
  to
  "-eth0-", "-eth1-", "-fxp0-" and "-fxp1-",
  respectively.

- In the i4ddCommand_1010 line, change to the new VIP address.

- In the DorbExternalIIOPHostName line, change to the new VIP address.

- Add the SocketUserDistributionCfg_1040 and SocketUserDistributionCfg_1050
  lines.

- Change the VipOspf lines.


IPv6 section:
- Add the IPv6 section.

- In the i4ddCommand_1100 line, change colons (:) to dashes (-), i.e.
  change
  ":eth0:" and ":eth1:"
  to
  "-eth0-" and "-eth1-",
  respectively.

- In the i4ddCommand_1110 line, change to the new VIP address.

- Change/Add the i4ddCommand_1120, SocketUserDistributionCfg_1100 and
  SocketUserDistributionCfg_1110 lines.

- Add the VipOspfV3 lines.

After modifying the epct file, rebuild the system and perform an initial load.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Set up external VIP traffic generator(s)
----------------------------------------
The procedure below must be repeated for each external VIP traffic generating
processor (non-cluster processor) to be used.

- Ask Lennart Viklund about which external VIP traffic generating processor(s)
  to use.

- Log in to the correct external VIP traffic generating processor:
    telnet 172.30.14.144       (Adjust 144 to valid processor, range 141 and up)
    login: telorb
    Password: tsP4ever
    cd vipTest/
      ls -l
        total 758
        -rw-r--r--   1 telorb   usr       106634 Jun 14 15:37 TG_144_v6.log
        -rw-r--r--   1 telorb   usr       131210 Jun 17 15:29 TG_144_v6_2.log
        -rw-r--r--   1 telorb   usr        49290 Jun 15 14:33 TG_144_v6b.log
        -rwxr-xr-x   1 telorb   usr        31564 May 14 10:24 VIPtrafficgenerator.LM_VIP101.R1A03.sparc-SunOS-5.6
        -rwxr-xr-x   1 telorb   usr        31652 May 14 10:24 VIPtrafficgeneratorIPv6.LM_VIP102.R1A01.sparc-SunOS-5.6
        -rwxr-xr-x   1 telorb   usr           89 May 14 10:41 esp1_v4.sh
        -rwxr-xr-x   1 telorb   usr           96 May 14 10:41 esp1_v6.sh
        -rwxr-xr-x   1 telorb   usr           87 May 18 14:07 to3_v4.sh
        -rwxr-xr-x   1 telorb   usr           94 May 18 14:07 to3_v6.sh

- If not already done, create new traffic generating files for your system (e.g.
  to11) and change the VIP address to suit your system:
    cp to3_v4.sh to11_v4.sh
    cp to3_v6.sh to11_v6.sh
    vi to11_v4.sh        (See `more' below. You only have to change the position
                          where it says `11' (to11))
    vi to11_v6.sh        (Same comments as for the vi command above)
    more to11_v4.sh
      #! /bin/sh
      ./VIPtrafficgenerator.LM_VIP101.R1A03.sparc-SunOS-5.6 172.30.14.11 5987 5988
    more to11_v6.sh
      #! /bin/sh
      ./VIPtrafficgeneratorIPv6.LM_VIP102.R1A01.sparc-SunOS-5.6 fec0:0:0:10::11 5989 5990

- Connection test: Ping the IPv4 VIP address for your system:
    /usr/sbin/ping 172.30.14.11          (Adjust IP address to suit your system)
      172.30.14.11 is alive              (Verify)

- Connection test: Ping the IPv6 VIP address for your system:
    /usr/sbin/ping fec0:0:0:10::11       (Adjust IP address to suit your system)
      fec0:0:0:10::11 is alive           (Verify)

If more than one external VIP traffic generating processors is to be used,
repeat the procedure above for this/these processor/processors.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Generate external VIP traffic
-----------------------------
You can either generate IPv4 and IPv6 traffic on the same external VIP traffic
generating processor (if only a small portion of traffic is to be generated)
(from different shells though), or you can use one processor for IPv4 and
another for IPv6, which is described below.

- Open windows for IPv4 and IPv6 (to start and stop VIP traffic from)
    cmdtool -Wl VIP_IPv4 &
    cmdtool -Wl VIP_IPv6 &

- In the VIP_IPv4 window, start the traffic generating process for IPv4 (on the
  valid external VIP traffic generating processor) as follows:
    telnet 172.30.14.144           (Log in to the correct external VIP traffic
                                    generating processor. Adjust 144 to valid
                                    processor, range 141 and up)
    login: telorb
    Password: tsP4ever
    cd vipTest/

    ./to11_v4.sh                (Start traffic. Adjust to11 to suit your system)
      --- Start of printout ---
      Parent pid=19375 about to fork
      Child pid=19376 VIPtrafficgenerator PEER_ADDRESS=172.30.14.11 PEER_CONFIGPORT=5987 PEER_TRAFFICPORT=5988
      --- End of printout ---

     To stop the traffic, enter Ctrl-c.

- In the VIP_IPv6 window, start the traffic generating process for IPv6 (on the
  valid external VIP traffic generating processor) as follows:
    telnet 172.30.14.145           (Log in to the correct external VIP traffic
                                    generating processor. Adjust 145 to valid
                                    processor, range 141 and up)
    login: telorb
    Password: tsP4ever
    cd vipTest/

    ./to11_v6.sh                (Start traffic. Adjust to11 to suit your system)
      --- Start of printout ---
      Parent pid=19378 about to fork
      Child pid=19379 VIPtrafficgenerator PEER_ADDRESS=fec0:0:0:10::11 PEER_CONFIGPORT=5989 PEER_TRAFFICPORT=5990
      --- End of printout ---

     To stop the traffic, enter Ctrl-c.

Set up the external VIP traffic scenario by using the TelORB Manager as follows:
- Populate.
- Select "External VIP traffic".
- Select "Dicos traffic" or "Linux traffic".        (Both kinds can be executing
                                                     simultaneously)
- Select "RUN" or "JRUN".                           (Both kinds can be executing
                                                     simultaneously)
    If you receive the message "Check your input values!", you have most
    probably forgotten to start the external VIP traffic process(es).

(To be completed...)

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Example of VIP configuration settings of site related data only (to11)
======================================================================

Mixed system (Dicos (Proc_m0_s21) and Linux (Proc_m0_s15))
----------------------------------------------------------
INITIAL DATA

// IPv4 VIP Commands
i4ddCommand_1000 = "ddconfig i4dd0 Proc_m0_s15-eth2-192.168.76.1 Proc_m0_s21-fxp0-192.168.77.2"

i4ddCommand_1010 = "ifconfig i4dd0 inet 172.30.14.11"

DorbExternalIIOPHostName = "172.30.14.11"

// IPv6 VIP Commands
i4ddCommand_1100 = "ddconfig i6dd0 Proc_m0_s15-eth2-fe80::20c:ceff:fe6c:2a10"

i4ddCommand_1110 = "ifconfig i6dd0 inet6 fec0:0:0:10::11"

ENDDATA


LinuxOnly
---------
INITIAL DATA

// IPv4 VIP Commands
i4ddCommand_1000 = "ddconfig i4dd0 Proc_m0_s15-eth2-192.168.76.1 Proc_m0_s21-eth3-192.168.77.2"

i4ddCommand_1010 = "ifconfig i4dd0 inet 172.30.14.11"

DorbExternalIIOPHostName = "172.30.14.11"

// IPv6 VIP Commands
i4ddCommand_1100 = "ddconfig i6dd0 Proc_m0_s15-eth2-fe80::20c:ceff:fe6c:2a10 Proc_m0_s21-eth3-fe80::20c:85ff:fe1a:9070"

i4ddCommand_1110 = "ifconfig i6dd0 inet6 fec0:0:0:10::11"

ENDDATA


DicosMax
--------
INITIAL DATA

// IPv4 VIP Commands
i4ddCommand_1000 = "ddconfig i4dd0 Proc_m0_s15-fxp1-192.168.76.1 Proc_m0_s21-fxp0-192.168.77.2"

i4ddCommand_1010 = "ifconfig i4dd0 inet 172.30.14.11"

DorbExternalIIOPHostName = "172.30.14.11"

ENDDATA

(172.30.14.11 = VIP address)

(Updated: 2004-06-09)

"RPM processes" running on IOs
------------------------------
telorb@Proc_m1_s1:~> ls -l /opt/telorb/etc/rc.d/init.d/
total 48
-rwxr-xr-x    1 root     root         4346 Jan 29  2004 CrashCollectorRpm
-rwxr-xr-x    1 root     root         5535 Mar  4  2004 DicosLogClientsRpm
-rwxr-xr-x    1 root     root         3493 Mar  5  2004 IoBinariesRpm
-rwxr-xr-x    1 root     root         4081 Jan 29  2004 STSswRpm
-rwxr-xr-x    1 root     root         3779 Mar 30  2004 TftpDumpRpm
-rwxr-xr-x    1 root     root         7772 Feb 24  2004 jreTP
-rwxr-xr-x    1 root     root         3016 Feb  6  2004 lm_d297_notif
-rwxr-xr-x    1 root     root         5963 Feb  6  2004 lm_d297_notif.functions

IoBinariesRpm is a dummy RPM which is always running.

On primary IO:
  /opt/telorb/etc/rc.d/init.d/DicosLogClientsRpm status
    runningg for DicosSyslogClient daemon: 
    runningg for DicosApplogClient daemon:

  You can also stop and start the "RPM processes" by adding stop/start instead
  of status to e.g. the command above.

(Updated: 2004-06-09)

"Heartbeat controlled" processes listed in /etc/ha.d/haresources on IO
----------------------------------------------------------------------
  more /etc/ha.d/haresources
    Proc_m2_s1 TIPCTAddrStarter::172.16.39.254 datadiskStarter nfsserverStarter
    sitedbStarter dhcpdStarter startTSPStarter EndResource

(Updated: 2004-06-09)

emacs <file_name> &
  Proc_m2_s1:/var/opt/tsp/epct # X11 connection rejected because of wrong
  authentication.
  Connection lost to X server `localhost:10.0'

export DISPLAY=134.138.186.45:0.0   (Adjust IP address to e.g. your WS) 
emacs <file_name> &                 (Should work now)

Another way of getting emacs to work is to start emacs with the following
parameter (to use emacs in this mode, you need to know
emacs short commands):
  emacs -nw <file_name>             (nw = no window. Note: Do not use
                                     `&' at the end of the command)
(Emacs will open up in the same window as you enter the emacs command in.)

(Updated: 2004-06-09)

The following is done to be able to access e.g. testbed and tbTEST software
outside the IO processor.
The instructions below should be performed on the IO processor where you want
to gain this access.

If you already have added lines to /etc/fstab and created extra directories as
described below, it is enough to perform the following and thereafter continue
where you came from:
    su                 (Enter superuser mode)
    Password: rootroot
    mount -av
    exit               (Exit superuser mode)

If you have not added lines to /etc/fstab and created extra directories as
described below, follow the instructions below and thereafter continue where
you came from.

- Enter root mode:
    su                 (Enter superuser mode)
    Password: rootroot

- Use e.g. emacs to add the subsequent lines at the end of the file /etc/fstab:
    emacs /etc/fstab &    (or use e.g. the VI editor)

134.138.185.10:/vol/vol3/export/u301/ipims_dicos            /ipims_dicos    nfs     soft,bg,intr,rw
134.138.185.10:/vol/vol3/export/u306/users/dicoshack        /home/dicoshack nfs     soft,intr,rw
134.138.185.10:/vol/vol3/export/u307/users/dicostest        /home/dicostest nfs     rsize=4096,wsize=4096,timeo=14,intr,rw
134.138.185.10:/vol/vol3/export/u305/users/dicosadm         /home/dicosadm  nfs     rsize=4096,wsize=4096,timeo=14,intr,rw
134.138.185.10:/vol/vol3/export/u308/users/dicosarc         /home/dicosarc  nfs     rw
134.138.185.10:/vol/vol4/export/u407/users/dicosarc2        /home/dicosarc2 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.185.10:/vol/vol3/export/u312/users/dicosarc3        /home/dicosarc3 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.185.10:/vol/vol3/export/u313/users/dicosarc4        /home/dicosarc4 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.185.10:/vol/vol3/export/u314/users/dicosarc5        /home/dicosarc5 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.185.10:/vol/vol3/export/u314/users/dicosarc5        /home/dicosarc5 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.185.10:/vol/vol3/export/u308/users/telorb           /mnt/home/telorb                nfs     soft,bg,intr,rw

134.138.185.10:/vol/vol4/export/u408/users/dicosarc6        /home/dicosarc6 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.185.10:/vol/vol4/export/u409/users/dicosarc7        /home/dicosarc7 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.226.4:/vol/vol6/export/u609/users/dicosarc8         /home/dicosarc8 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.226.4:/vol/vol6/export/u610/users/dicosarc9         /home/dicosarc9 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.226.4:/vol/vol6/export/u611/users/dicosarc10        /home/dicosarc10 nfs rsize=8192,wsize=8192,timeo=14,intr,rw

134.138.226.4:/vol/vol7/export/u703/users/dicosarc11        /home/dicosarc11 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.226.4:/vol/vol7/export/u704/users/dicosarc12        /home/dicosarc12 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.226.4:/vol/vol7/export/u705/users/dicosarc13        /home/dicosarc13 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.226.4:/vol/vol7/export/u706/users/dicosarc14        /home/dicosarc14 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
134.138.226.4:/vol/vol7/export/u707/users/dicosarc15        /home/dicosarc15 nfs rsize=8192,wsize=8192,timeo=14,intr,rw

  (Note: If you are using the editor emacs and this results in
   "...X11 connection rejected..." enter the following command:
     export DISPLAY=134.138.186.45:0.0   (Adjust IP address to e.g. your WS))

- Backup the file:
    cp /etc/fstab /etc/fstab.uab

- Create the following directories (still as root):
    cd /home/
    mkdir dicoshack dicostest dicosadm dicosarc dicosarc2 dicosarc3 dicosarc4 dicosarc5 dicosarc6 dicosarc7
    mkdir dicosarc8 dicosarc9 dicosarc10 dicosarc11 dicosarc12 dicosarc13 dicosarc14 dicosarc15
    mkdir -p /mnt/home/telorb
    mkdir /ipims_dicos

- Make it possible to access dicosarc8-15 (uabn4: 134.138.226.4)
  (rest of the files (e.g. dicosarc5) are accessed through uabn8: 134.138.185.10):
    route add -host 134.138.226.4 gw 134.138.184.1
    route -n                                              (Verify result)

- Mount all new directories:
    mount -av

- Exit superuser mode:
    exit

(Updated: 2004-06-09)

On IO1:
  su
  psw
  cd /var/opt/tsp/epct/          (Create these directories if they do not exist)
  scp 134.138.187.55:/var/opt/tsp/epct/* .   (Adjust IP address (to14io2))
  exit

(Updated: 2004-06-09)

The "pingall" script can be executed on any of the IO processors to get the
status of all processors, GESBs and SCBs in the system.

This section describes how to copy the "pingall" script from Michel's Hack
location to current IO as follows.

On current IO:
  cd /home/telorb/
  scp telorb@134.138.186.45:/home/dicoshack/Hack/uabmsu/pingall/ping_all_tsp5.0 .
  Password: tsP4ever
  chmod 755 ping_all_tsp5.0

  (Or copy the script from a local workstation:
    cd /home/telorb/to15peo/
    scp ping_all_tsp5.0 to11io2:            (The script will end up in directory
                                             /home/telorb/))

While at it, you may also copy the following nice to have "scripts" to the IO
processor(s):

Script for starting only a few processor consoles (STS windows):
  scp telorb@134.138.186.45:/home/dicoshack/Hack/uabmsu/pingall/start_sts .
    (Adjust the script to match your system) (See contents below)

Script for ending all processor consoles (STS windows):
  scp telorb@134.138.186.45:/home/dicoshack/Hack/uabmsu/pingall/kill_STS .
    (See contents below)

Script to check the sync time between the IO processors:
  scp telorb@134.138.186.45:/home/dicoshack/Hack/uabmsu/pingall/check_sync_time .
    (See contents below)


start_sts
---------
STS_console --font 7x14 3 9 13 20 25 31 40 42 --bg-linux --config /opt/telorb/axe/loadingGroup01_1/to14.config


kill_STS
--------
#!/bin/sh

pid=`ps -e | grep STS | awk '{print $1}'`

if [ "$pid" = "" ]
then
   echo " The process is not running"

else 
   echo $pid
   rm /opt/telorb/axe/tsp/consolelogs/Proc*
   kill $pid

fi


check_sync_time 
---------------
#!/bin/sh

flag_1=0
flag_2=0
flag_3=0
START_TIME=
SYNC=
SPEED=
file=/proc/drbd

while true;do
  
   cat $file | grep SyncingAll > /dev/null

      if [ $? = 0 ];then
         flag_1=1
         if [ $flag_2 = 0 ];then
            START_TIME=`date '+START_TIME:%H:%M:%S'`
            SYNC=`awk '/sync/ {print "\t" $3}' /proc/drbd`
            SPEED=`awk '/speed/ {print "\t" $4,$5,$6}' /proc/drbd`
            echo $START_TIME 
            echo "Sync'ed:$SYNC"
            echo "speed: $SPEED"
            flag_2=1
         else 
            SYNC=`awk '/sync/ {print "\t" $3}' /proc/drbd`
            SPEED=`awk '/speed/ {print "\t\t" $4,$5,$6}' /proc/drbd`
            echo "********"
            echo "Sync'ed:$SYNC"
            echo "speed: $SPEED"
         fi
      else
         if [ $flag_1 = 1 ];then
            echo $START_TIME
            date '+FINISH_TIME:%H:%M:%S' 
            exit
          else
              if [ $flag_3 = 0 ];then
                 echo "FullSync has not started ..."
                 flag_3=1
               fi

         fi
      fi

   sleep 2
done

(Updated: 2004-06-22)

Perform the following on the IO where the error dump resides.

- Go to the error dump location, e.g.
    cd /opt/telorb/axe/tsp/crashcollector/temp0406211729_Proc_m1_s1/
                (Adjust temp0406211729_Proc_m1_s1 to valid error dump directory)

- To be able to access e.g. testbed and tbTEST software outside the IO
  processor, follow the instructions at Mount EAB CW/OS lab environment on IOs.

  tcsh
  source /ipims_dicos/ipims_dicos20/BS2/tbWP124/Setup.csh
                                               (Adjust tbWP124 to valid release)
    -or-
  source /ipims_dicos/BS2/tbLSV15/Setup.csh
                                               (Adjust tbLSV15 to valid release)
                                    (The sourcing will set up the EP_CONFIGPATH
                                    which is necessary to execute epelfaddr_dmp)

  epelfaddr_dmp -d DicosCapsuleTextDump.172.16.8.145-1
                (Adjust DicosCapsuleTextDump.172.16.8.145-1 to valid error dump)

  (Old info:
   tcsh
   source /ipims_dicos/ipims_dicos20/BS2/tbAD15.6/IP_CONF_INFO/EnvSettings
                                             (Adjust tbAD15.6 to valid release))

(Updated: 2005-05-24)

epelfaddr in TSP 5
------------------
E.g. core.t1116851697.hProc_m1_s9.u0.g0.s6.p10267.lmstarter-report.txt.gz.172.16.0.137-2
  and
core.t1116851697.hProc_m1_s9.u0.g0.s6.p10267.lmstarter.gz.172.16.0.137-1

To get a quick look at what the core dump is all about, you can read the
belonging report file as follows. If not, skip this part and start interpreting
the real core dump as described further down:

- Read the report file by performing the following instructions on one of the
  IOs:
  - Unpack the report file:
      cd /opt/telorb/axe/tsp/crashcollector/
      tar zxf crashcollector0505231448_Proc_m2_s1.tar.Z   (Adjust to valid file)
      cd temp0505231448_Proc_m2_s1                   (Adjust to valid directory)

  - Add the suffix .gz at the end of the core dump file name:
      cp <core_dump_file_name> <core_dump_file_name.gz>

  - Rename the original core dump file, if you want to save it:
      mv <core_dump_file_name> <core_dump_file_name.orig>

  - Expand the report file:
      gunzip <core_dump_file_name.gz>

  - Read the report file:
      less core.t1116851697.hProc_m1_s9.u0.g0.s6.p10267.lmstarter-report.txt.gz.172.16.0.137-2
                                                          (Adjust to valid file)

- Interpret the core dump by performing the following instructions on one of the
  IOs:
  - To be able to access e.g. testbed and tbTEST software outside the IO
    processor, follow the instructions provided in
    Mount EAB CW/OS lab environment on IOs.

  - Interpret the core dump:
      cd /opt/telorb/axe/tsp/crashcollector/
      tar zxf crashcollector0505231448_Proc_m2_s1.tar.Z   (Adjust to valid file)
      cd temp0505231448_Proc_m2_s1                   (Adjust to valid directory)

  - Add the suffix .gz at the end of the core dump file name:
      cp <core_dump_file_name> <core_dump_file_name.gz>

  - Rename the original core dump file, if you want to save it:
      mv <core_dump_file_name> <core_dump_file_name.orig>

  - Expand the core dump file:
      gunzip <core_dump_file_name.gz>

  - Interpret the core dump file:
      tcsh
      source /ipims_dicos/BS2/tbWP0xx/Setup.csh   (Adjust tbWP0xx to valid work
                                                   package)
      epelfaddr_dmp -d <core_dump_file_name>

-- -- -- -- -- --

Alternative:
1) Se till att du kör på en linux-burk (t ex tos2)
2) Kopiera över en core-dump från crashcollectorn, lägg till .gz i
   slutet av filen
3) gunzip filnamn (ex gunzip core.gz)
4) epconfig s /ipims_dicos/BS2/devenv4.0/DevEnv_IDPG/DeploymentTools_IDP/DeploymentToolsLib_LM/
5) epelfaddr_dmp -d filnamn (ex epelfaddr_dmp -d core)
(Source: E-mail from Krister Nilsson via Peder Magnusson, 2005-01-11)

---------------------------------------------------------------------

The following section will be translated later.

Hej
Har pratat med Jörgen och det här gjorde han på min iomaskin (to13io1)

Man tager i sin crashcollector sin dump och tarar upp den, i mitt fall:
- tar xzvf crashcollector0406211915_Proc_m2_s1.tar.Z
Man går till resultatfilen :
- cd temp0406211915_Proc_m2_s1/
Man tarar upp Linuxdumpen :
- tar zxvf LinuxProcessorDump-172.16.0.21-2004-06-21-19:10.tgz
--force-local
Man går till resultatfilen :
- cd 172.16.0.21-2004-06-21-19:10
Man kör ett verktyg för att titta på dumpen, hur det funkar vet jag inte
:
- /sbin/lcrash -m /boot/System.map-2.4.21-R2A42 -t
/boot/Kerntypes-2.4.21-R2A42 -d vmcore

Om det är någon som fattar hur man sen gör så kan ni höra av er.

/John Vaksdal
(Source: E-mail from John Vaksdal with input from Jörgen Karlsson, 2004-06-22)

(Updated: 2004-10-07)

All epct template files (from the installation) are located in the following
directory:
  /opt/telorb/axe/runtimes/TelORB-R15-LSV510-Runtime/config/epct/
                                            (Adjust R15-LSV510 to valid release)

(Updated: 2004-06-09)

Crash collector files are stored in the following directory:
  /opt/telorb/axe/tsp/crashcollector/

(Updated: 2004-06-21)

These instructions are no longer valid!!!
I will rewrite them as soon as time permits!

Log in to the primary IO processor:
  ssh telorb@toXioY                       (Adjust toXioY to valid system and IO)

Verify that you are logged in to the primary IO:
  cat /proc/drbd                          (Should show ...Primary/Secondary...)

Start a full sync:
  su -
  psw 
  drbdsetup /dev/nb0 replicate
  exit

(Updated: 2004-06-21)

Any modifications to the site database, using the sitedbclient commands, must
be performed from the primary IO.
Nothing has to be done, after the sitedbclient command has been sent, to make
the modification(s) take effect, i.e. stopping and starting sitedb is NOT
necessary.
Any values, such as IP and MAC addresses, in the examples below, must be
adjusted to suit your system.
If you do not know whether to use `THE' or not, then always use it. (The
original code always expects `THE', but Lars Ekman has simplified this by
making it possible to omit `THE' in some cases (see below).)

Get sitedbclient instructions:
  On IO:
    sitedbclient -h

Gives the following help text:

sitedbclient -- A TSP site data-base client
	The tspsitedb_client queries or modifies the TSP site data-base.
	The SOAP protocol is used to communicate with the site data-base
	server.

	The tspsitedb_client is a generic tool and requires knowledge
	of the internal structure of the TSP site data-base. The best
	way to get this knowledge is to read the DTD for the TSP site
	data-base (found in SWI/D358, TspSiteDb_SWI).

	It is undesirable to expose the internal structure, so a new
	interface might be available in the future.

    Syntax:
	sitedbclient [options] operation [item key]+ [value]

    Options:
	--help, -h
		This printout.
	--debug=%d, -d %d
		Set debug printout level. 0=silent, 9=verbose, 5=default.
	--server-url=<URL>
		The URL of the TSP site data-base server.
		Default: <http://localhost:8081>
       --xml-faults
               Report any SOAP faults with XML details.
       --no-xml-faults
               Report any SOAP faults as simple text.
               This is the current default behaviour.
       --print0
       --print-nl
               Terminates each returned item with a null/newline
               character. In this case, an empty result is not an error.

    operation -
	Can be any one of: query, add, remove, modify

    item key -
	At least one [tem,key] pair must be specified. More pairs are
	used to specify a sub-item, such as an Interface on a
	Processor. The key is a field and a value with a '=' between,
	or the special keys THE or fld=ALL. THE is used when accessing
	a 'singelton' item (e.g ZoneId). ALL is used to get a list of
	a field for all items of a particular type, e.g all processor
	names.

    value -
	Is only used with the 'modify' operation.

    Shortcuts (see also 'Examples' below):
	A tailing 'THE' key may be omitted for query and modify.

	The (Processors THE) may be omitted if followed by a
	'Processor' item.

	The (Interfaces THE) may be omitted if followed by a
	'EthernetInterface' item.

	NOTE: these shortcuts are a feature of this client program,
	the SOAP interface has NO shortcuts itself!

    Examples:
	sitedbclient query zoneid THE		# (correct)
	sitedbclient query zoneid		# (shortcut)

	sitedbclient add Network in_addr=172.16.0.0
	sitedbclient modify Network in_addr=172.16.0.0 netmask THE 255.255.0.0
	sitedbclient add Network in_addr=172.17.0.0
	sitedbclient modify Network in_addr=172.17.0.0 netmask 255.255.0.0
	sitedbclient query Network in_addr=ALL

	sitedbclient add Processors THE Processor hwid=0x10A8
	sitedbclient modify Processors THE Processor hwid=0x10A8 name Proc_m0_s9
	sitedbclient modify Processor name=Proc_m0_s9 type IO
	sitedbclient add Processors THE Processor name=Proc_m0_s9  \ 
		Interfaces THE EthernetInterface macaddress=00:01:02:03:04:05
	sitedbclient modify Processor name=Proc_m0_s9  \ 
		EthernetInterface macaddress=00:01:02:03:04:05 \ 
		in_addr 172.17.0.101
	sitedbclient add Processor name=Proc_m0_s9  \ 
		EthernetInterface macaddress=00:01:02:03:04:10
	sitedbclient modify Processor name=Proc_m0_s9  \ 
		EthernetInterface macaddress=00:01:02:03:04:10 \ 
		in_addr 172.16.0.101

	sitedbclient add Processors THE Processor hwid=0x6FF8
	sitedbclient modify Processors THE Processor hwid=0x6FF8 name Proc_m0_s11
	sitedbclient modify Processor name=Proc_m0_s11 type Dicos-TP

	sitedbclient query Processors THE Processor name=ALL
	sitedbclient query Processors THE Processor hwid=0x6FF8 type
	sitedbclient query Processors THE Processor hwid=0x10A8 \ 
		Interfaces THE EthernetInterface macaddress=ALL

-- -- -- -- -- --

Real life examples
==================

Check contents of the site database file on one of the IO processors:
  cd /opt/telorb/axe/adm/etc/
  less dbfile.xml


Add VIP interface (external) IP addresses to the Site Database file
dbfile.xml
-------------------------------------------------------------------
E.g. modify the eth3 address (VIP) for Proc_m0_s5 with MAC address
00:20:ce:c8:13:6f as telorb user:
  sitedbclient modify Processor name=Proc_m0_s5 EthernetInterface macaddress=00:20:ce:c8:13:6f in_addr 192.168.77.161

E.g. modify the eth3 address (VIP) for Proc_m0_s1 with MAC address
00:20:ce:c8:06:e3 as telorb user:
  sitedbclient modify Processor name=Proc_m0_s1 EthernetInterface macaddress=00:20:ce:c8:06:e3 in_addr 192.168.76.160

Also update the E10cwos_initial.epct file with i4dd IP addresses, e.g. add:
  i4ddCommand_1000 = "ddconfig i4dd0 Proc_m0_s1:eth3:192.168.76.1 Proc_m0_s5:eth3:192.168.77.2"
  (If another command uses "i4ddCommand_1000", adjust the values (1000, 1010 and
   1020.))
Then rerun the epct command (build the system) and initially load the system.


Modify the external IP address (e.g. eth2) for e.g. an IO processor
(e.g. Proc_m1_s1) in the Site Database file dbfile.xml
-------------------------------------------------------------------
sitedbclient modify Processor name=Proc_m1_s1 EthernetInterface macaddress=00:20:ce:c8:14:2e in_addr 134.138.187.44
Then reload the processor for which you modified the IP address.


Remove a processor from the site database file
----------------------------------------------
sitedbclient remove Processor hwid=00:20:ce:c8:13:84

If e.g. a processor does not load and you want to replace it hardwarewise, you
must first delete the processor entry in the site database file by using e.g.
the sitedbclient command above, for the replacement processor to start probing.
In the probing phase, the site database file will be automatically updated with
data about the replacement processor.


Remove an SCB from the site database file
-----------------------------------------
sitedbclient remove DeviceBoards THE DeviceBoard name=SCB_5A
(This removes the SCB entry from the Site Database file, but the SCB is still
in the system software-wise. To completely remove the SCB from the system, you
have to remove the SCB entry from the epct file and then rebuild the system.
Alternatively, none of the actions above, but remove them from the epct file
when performing an initial installation of the system.)


Change the type of a processor to FS (File Server) in the site database file
----------------------------------------------------------------------------
This must be used when an FS is added to the system. This will be fixed later
on.
sitedbclient modify Processor hwid=00:20:ce:c8:13:84 type FS


View the external VIP address
-----------------------------
sitedbclient query ZoneData THE DnsData name=platform-vip in_addresses


Modify the external VIP address in the site database file
---------------------------------------------------------
sitedbclient modify ZoneData THE DnsData name=platform-vip in_addresses 172.30.14.11


Modify the "VIP prefix" in the site database file
-------------------------------------------------
sitedbclient modify Network name=vip-net-0x0 prefix 192.168.76.0/24
sitedbclient modify Network name=vip-net-0x1 prefix 192.168.77.0/24

Perform a zone reload to make the changes take effect. (Is it really necessary
to perform such a drastic measure?)


Change IO processor to put processor logs in (/opt/telorb/axe/tsp/consolelogs)
------------------------------------------------------------------------------
sitedbclient modify ZoneData THE InitData name=stsconfig value 172.16.1.1


Replace the name of the processor, ip-address and mac-address
-------------------------------------------------------------
(Info from Roger Nilsson, 2005-05-12)
Here are the commands that needs to be entered if you have replaced one
IO machine and the external network is not up and running. Replace the
name of the processor, ip-address and mac-address below to match your
processor/system.

Note: Every sitedbclient command needs to be entered on one line!

sitedbclient add Processor name=Proc_m1_s1 Network name=external-0

sitedbclient modify Processor name=Proc_m1_s1 Network name=external-0
addrs 134.138.187.20

sitedbclient modify Processor name=Proc_m1_s1 EthernetInterface
macaddress=00:20:ce:c8:0d:3a lnw EN-0

sitedbclient modify Processor name=Proc_m1_s1 EthernetInterface
macaddress=00:20:ce:c8:0d:3a conf autoneg

sitedbclient modify Processor name=Proc_m1_s1 EthernetInterface
macaddress=00:20:ce:c8:0d:3a state up

Reboot the IO processor to make the changes take effect.


Wrong IP address on an external ethernet interface on a processor used as VIP
frontend.
-----------------------------------------------------------------------------
In this example
- - - - - - - -
Processor:   Proc_m0_s19
Old address: 172.39.19.188
New address: 172.39.19.190

Print the existing network and Osp data for the processor from the dbfile.xml:

less /opt/telorb/axe/adm/etc/dbfile.xml

----- Part of the file -----
<tsp:name>Proc_m0_s19</tsp:name>
...
<tsp:name>vip-net-0x1</tsp:name>
  <tsp:addrs>172.30.19.188</tsp:addrs>
</tsp:Network>
...
<tsp:Ospf>
  <tsp:routerId>172.30.19.188</tsp:routerId>
  <tsp:areaId>10.0.0.1</tsp:areaId>
  <tsp:deadItvl>40</tsp:deadItvl>
  <tsp:helloItvl>10</tsp:helloItvl>
  <tsp:network>vip-net-0x1</tsp:network>
  <tsp:I4dd>
    <tsp:name>i4dd0</tsp:name>
    <tsp:gws>172.30.19.189</tsp:gws>
  </tsp:I4dd>
</tsp:Ospf>
---- Part of the file -----

Change the adress in the network
- - - - - - - - - - - - - - - - -
sitedbclient modify Processor name=Proc_m0_s19 Network name=vip-net-0x1 addrs 172.30.19.190

Remove Ospf
- - - - - -
sitedbclient remove Processor name=Proc_m0_s19 Ospf routerId=172.30.19.188

Add new Ospf
- - - - - - -
sitedbclient add Processor name=Proc_m0_s19 Ospf routerId=172.30.19.190
sitedbclient modify Processor name=Proc_m0_s19 Ospf routerId=172.30.19.190 areaId 10.0.0.1
sitedbclient modify Processor name=Proc_m0_s19 Ospf routerId=172.30.19.190 deadItvl 40
sitedbclient modify Processor name=Proc_m0_s19 Ospf routerId=172.30.19.190 helloItvl 10
sitedbclient modify Processor name=Proc_m0_s19 Ospf routerId=172.30.19.190 network vip-net-0x1
sitedbclient add Processor name=Proc_m0_s19 Ospf routerId=172.30.19.190 I4dd name=i4dd0
sitedbclient modify Processor name=Proc_m0_s19 Ospf routerId=172.30.19.190 I4dd name=i4dd0 gws 172.30.19.189

(Source: E-mail from Andreas Johansson, 2005-10-14)

(Updated: 2005-10-06)

Change Site Database file:
  cp dbfile.xml dbfile.xml.orig
  cp dbfile.xml dbfile.xml.msu
  vi dbfile.xml.msu              (Make your changes)
  su -
  cd /opt/mirror/adm/etc
  cp dbfile.xml.msu dbfile.xml
  ps -ef | grep sitedbserver
  kill -9 <pid>
  ps -ef | grep sitedbserver     (Verify that the sitedbserver has restarted)

(Info from Krister Nilsson, 2005-10-03)

-- -- -- -- -- --

Old way, probably no longer valid:

Stop the IO monitor on both IOs:
  Note: Wait for the printout "done", before stopping IO monitor on the other
  IO, to avoid the risk of the IO monitor rebooting the IO.
  su
  /etc/init.d/monitord stop

Both IOs should show Secondary/Secondary when entering the following command:
  cat /proc/drbd

Enter the following commands on any of the IOs to mount '/opt/mirror':
  (/etc/monitor.d/drbd/up)
  /etc/monitor.d/drbd/primary
  /etc/monitor.d/wait/drbd0 start

Now you can change the Site Database file on any of the IOs:
  su
  cd /opt/mirror/adm/etc/
  mv dbfile.xml dbfile.xml.orig
Edit the dbfile.xml using a suitable editor.
Restart the sitedb:
  /opt/telorb/bin/sitedb_restart

Restore drbd on any of the IOs:
  /etc/monitor.d/wait/drbd0 stop
  /etc/monitor.d/drbd/secondary
  (/etc/monitor.d/drbd/down)

Start IO monitor on both IOs:
  su
  /etc/init.d/monitord start 

(Info from Per Lidén via Roger Nilsson, 2005-05-12)

-- -- -- -- -- --

Old way, no longer valid:

Note: Do not attempt to use this procedure unless you know what you are doing.
      You may end up in a very unpleasant state. The instructions below are
      outdated, but I will keep them here, since they may be useful to me.

It is possible to write directly in the Site Database file dbfile.xml, but
this is more complicated than using the sitedbclient. E.g. processes have to be
stopped as described below.
Preferably, use the sitedbclient for this purpose:
  Modify the Site Database file dbfile.xml using the sitedbclient.

su
/etc/init.d/sitedb stop
/etc/init.d/dhcpd stop
/etc/init.d/named stop
/etc/init.d/xntpd stop

(export DISPLAY=134.138.186.45:0.0)          (To get emacs to work, adjust IP
                                              address to your workstation)
emacs /opt/mirror/adm/etc/dbfile.xml &       (/opt/telorb/axe/adm/etc/dbfile.xml
                                              will be updated on both IOs)

  E.g. find the word "null" and replace it with "0.0.0.0".

Save the file.

/etc/init.d/sitedb start  (dhcpd and named will also start)
                          (If sitedb is not started, check who has taken port
                           8081:
                             netstat -lpn | grep 8081
                           Stop that process, e.g. /etc/init.d/xntpd stop
                           and then try to start sitedb again. This may have to
                           be repeated)
/etc/init.d/xntpd start
exit

(Updated: 2004-06-28)

Prevent TSP to start on IO
--------------------------
As root on IO (either in ordinary processor window or on serial terminal):
  insserv -rf tsp.init    (Removes the tsp.init startscript @ /etc/init.d/rc3.d)

     (The next time, when the processor reboots, TSP will not start)

Verify with:
  ls /etc/init.d/rc3.d    (The SXXtsp.init startscript should not exist)

Restore
-------
Add the tsp.init startscript as root (i.e. set it back to normal):
  insserv -f tsp.init     (Adds the tsp.init startscript @ /etc/init.d/rc3.d)
Verify with:
  ls /etc/init.d/rc3.d    (The SXXtsp.init startscript should exist)

Stop/start 'tsp' manually (These settings will not survive a reboot)
-------------------------
/etc/init.d/tsp.init stop
/etc/init.d/tsp.init start

(Updated: 2004-04-07)

Before performing the following, the IOs must be synched.

Verify that the IOs are synched:
  cat /proc/drbd

Perform the following as root:

  Secondary IO:
    /etc/init.d/heartbeat stop

  Primary IO:
    /etc/init.d/heartbeat stop

  Secondary IO:
    /etc/init.d/drbd stop

  Primary IO:
    /etc/init.d/drbd stop 
(Source: Info from Peder Magnusson, 2004-04-07)

(Updated: 2004-06-09)

ssh telorb@utmp05
Password: tsP4ever
su root

Edit /etc/minirc.xx (where xx is 0 to 15 according to the connector number on
the connection plate) if necessary. It should look as follows where ttyR14
should be adjusted to the correct connector number and the baudrate should be
adjusted to suit the target processor (TSP 5.0 processors => 38400):

  # Machine-generated file - use "minicom -s" to change parameters.
  pr port             /dev/ttyR14
  pu baudrate         38400
  pu bits             8
  pu parity           N
  pu stopbits         1
  pu minit            
  pu mreset           
  pu rtscts           No

exit


minicom xx (where xx is 0 to 15 according to the connector number on the
connection plate)

(Updated: 2004-06-09)

Shrink DRBD partition to 6GB to speed up the IO synching
--------------------------------------------------------

Make serial connections to both IO processors to see possible errors if
any.

1. On SECONDARY IO ( Check IO status in /proc/drbd file), Do the
following:
  
-----------------------------------------------------------------------

* Take a backup of "/boot/DRBD.size" file. Just in case.

# cp /boot/DRBD.size ~/DRBD.size

* Change the partition size to 6GB.
   
# echo "/dev/mirror/opttelorblv 12000000" >/boot/DRBD.size

* Remove old information.

# rm /var/lib/drbd/*

* Remove tsp.init link from rc3.d level.

# insserv -rf tsp.init

* Take down the IO processor with "shutdown" command and remove it can
from the cabinet. The IO must not be restarted otherwise the old drbd
information will be transfered by PRIMARY IO. Even if the processor
has been halted, the watchdog will restart the processor.

# /sbin/shutdown -h now


2. On PRIMARY IO, do the following:
   --------------------------------

# insserv -rf tsp.init  
# /sbin/shutdown -r now

* Wait until the IO has been rebooted and log back on to the IO (using
ssh or a serial terminal).

* Wait until /dev/nb0 (/opt/mirror) has been mounted (use the mount
command to check if it is mounted).

# mount

* When /opt/mirror directory has been mounted, do the following:

* Take a backup of "/boot/DRBD.size" file. Just in case.

# cp /boot/DRBD.size ~/DRBD.size

# echo "/dev/mirror/opttelorblv 12000000" >/boot/DRBD.size

# /etc/init.d/heartbeat stop 

# cd /root

* if the output of "cat /proc/drbd is the following: "0: cs:WFConnection
st:Secondary/Unknown ns:0 nr:0 dw:3064 dr:103578 pe:0 ua:0.", the IO
processor has been changed to SECONDARY. Change it with "drbd" script
and answer "yes" to question "Do you want to abort waiting for other
server and make this one primary?".

#/etc/init.d/drbd start

# mount /opt/mirror

* Edit /opt/mirror/adm/etc/dbfile.xml and change partition_size in
"tsp:ProcessorPair" to 12000000 so it looks like:
         <tsp:ProcessorPair>
            <tsp:pair_id>io</tsp:pair_id>
                :
            <tsp:partition_size>12000000</tsp:partition_size>
         </tsp:ProcessorPair>


# tar -C /opt/mirror -zcf /root/backup.tgz . 
# umount /opt/mirror
# /etc/init.d/drbd stop
# insmod drbd
# drbdsetup /dev/nb0 disk /dev/mirror/opttelorblv
--disk-size=6000000        
# drbdsetup /dev/nb0 primary
# mkfs.ext3 /dev/nb0 
# mount /opt/mirror
# tar -C /opt/mirror -zxf /root/backup.tgz
# rm /root/backup.tgz
# umount /opt/mirror
# rm /var/lib/drbd/*            
# /sbin/shutdown -r now 
    
* Wait until the IO has rebooted.

3. Power on the SECONDARY IO
   -------------------------
Insert the IO into the magazine if it was previously removed. Wait until
the IO has rebooted.

4. Create tsp.init link in both IO processors.
   -------------------------------------------

# insserv -f tsp.init
/sbin/shutdown -r now

(Source: E-mail from Jorge Martinez with input from Jörgen Karlsson, 2004-04-26)

(Updated: 2004-10-22)

These instructions describe how to replace a processor of the types TP, FS and
IO.

The replacement procedure should only be used when replacing a processor of the
same kind (with or without disk) and same type (TP, FS, IO).
Thus, do not use this procedure when e.g. swaping an FS to a TP. For this
purpose, use the "Removing Processor" and "Adding Processor" procedures.

At the time when I wrote these instructions, no official document describing
how to accomplish this existed.

Have in mind that the instructions are written from an educational point of
view, i.e. with a lot of checkpoints where some steps are not necessary to
perform.


Preinstructions
---------------
It is not recommended to replace more than one processor in one go, due to that
traffical disturbances may occur.
However, it is possible to replace several TPs (with or without disk) in one go,
but when it comes to IO and FS processors, these should always be replaced one
by one.
Additionally, if a processor to be replaced has external interface(s) (e.g. VIP
links or using e.g. eth2, eth3), only one processor at a time can be replaced. This is due to the "transfer" of the external IP address(es) to the new
processor in the Site Database. See my TR HE97456.


Select which processor type you want to replace
-----------------------------------------------
  o Traffic Processor without disk   (TP)
  o Traffic Processor with disk      (TP with disk, FS or IO)


Instructions for replacing a TP without disk
--------------------------------------------
 1. In the "Processor HW" card in the "Processor HW" area in the TelORB Manager:
    - Click "Refresh" to update the processor list.
    - Click the processor to be replaced. (Actually, not necessary.)
    - Take a note of the processor's MAC address, i.e. its "hwid".

 2. Make sure that you have a valid replacement processor.

 3. In the Home card in the TelORB Manager:
    Click the "Refresh" button to update the "Zone State" value.

 4. Verify that "Zone State" is "Idle".
    If "Zone State" is not "Idle", the system is busy with something else that
    must finish before the disable/enable operations further down in these
    instructions can be accepted. In this case, wait for "Zone State" to become
    "Idle".

 5. Check the status of the processor to be replaced, by performing the
    following in the "Processors" card in the TelORB Manager:
    - Click "Rescan" to update the upper processor list.
    - Click the processor to be replaced.
    - Check if the processor is already disabled, i.e. if the "Status" of the
      processor is "Out of Service". (If so, the processor should be red-
      marked in the upper processor list and the alarm "Processor
      Disabled" should exist in the alarm log.)

    - If the processor "Status" is "Out of Service", skip to step 7.
    - If the processor "Status" is "In Service", continue below.

 6. Disable the processor to be replaced, by performing the following in the
    "Processors" card in the TelORB Manager (with the valid processor still
     selected):
    - Click the processor to be replaced (if not already selected).
    - Click "Disable" and answer "Yes" to the popup question.
        Notification: "Disable Processor Started".
    - Wait for the processor to be disabled.
        Notification: "Disable Processor Finished Successfully".
        Alarm: "Processor Disabled".
    - Click "Rescan" to update the upper processor list.
    - Verify that the processor to be replaced is red-marked.
    - Click the processor to be replaced.
    - Verify that the "Status" of the processor is "Out of Service".

 7. Physically, disconnect any cables at the front of the processor to be
    replaced, and then disconnect the processor from the magazine.
      Alarm: "Hardware configuration is changed".

 8. In the "Hardware" card in the TelORB Manager:
    - Click "Rescan" to update the Hardware card.
    - Click the Mag <n> tab for the magazine where the disconnected
      processor was located.
    - Verify that the text "(Changed)" is displayed for the disconnected board.

 9. Physically, connect the new (replacement) processor and then connect any
    cables to its front.
    (If you want to follow e.g. the probing and restarting activities of the
    new processor, connect and set up a serial terminal connection to the
    processor to be able to monitor it.)

10. In the "Processor HW" card in the "Processor HW" area in the TelORB Manager:
    - Repeatedly click "Refresh", to update the processor list, until the
      processor's MAC address, i.e. "hwid", has changed. (If the processor was
      not listed at the bottom of the list before it was connected, it will be
      so now.)
      (On serial terminal to Dicos TP: "-----> ColspPromLoader::entering the
      while loop")
      (On serial terminal to Linux TP: Cyclic reloading.)

11. Enable the new processor, by performing the following in the "Processors"
    card in the TelORB Manager:
    - Click "Rescan" to update the upper processor list.
    - Click the new (still red-marked) processor.
    - Click "Enable" and answer "Yes" to the popup question.
        Notification: "Enable Processor Started".

12. Wait for the processor to be enabled.
      Notification: "Enable Processor Finished Successfully".
      Alarm cleared: "Processor Disabled".

13. In the "Processors" card in the TelORB Manager:
    - Click "Rescan" to update the upper processor list.
    - Verify that the new processor is green-marked.
    - Click the new processor.
    - Verify that the "Status" of the new processor is "In Service".

14. In the "Hardware" card in the TelORB Manager:
    - Click "Rescan" to update the Hardware card.
    - Click the Mag <n> tab for the magazine where the new processor is
      located.
    - Click the new processor (with the "(Changed)" text on it).
    - Verify the information in the Card Information area and then click
      "Approve Change".
      (The "(Changed)" text immediately disappears.)
        Alarm cleared: "Hardware configuration is changed".

The replacing processor procedure is now completed and the new processor should
be in service.

It is not necessary to create a backup, since only the MAC-address fields
(<tsp:hwid> and <tsp:macaddress>) for the replaced processor has
been changed in the Site Database file (/opt/telorb/axe/adm/etc/dbfile.xml on
IO).


Instructions for replacing a TP with disk, File Server or IO Processor
----------------------------------------------------------------------
Note: Some of the steps in this procedure are time critical, i.e. you have to
      act within seconds for these steps to be able to complete this procedure
      in a straightforward manner. Such steps are indicated with red text
      below.
      Thus, read the instructions for each step completely through, before
      starting to act on them.
      (I have issued TR HFxxxxx on this matter.)
 
 1. In the "Processor HW" card in the "Processor HW" area in the TelORB Manager:
    - Click "Refresh" to update the processor list.
    - Click the processor to be replaced. (Actually, not necessary.)
    - Take a note of the processor's MAC address, i.e. its "hwid".

 2. Make sure that you have a valid replacement processor.

 3. In the Home card in the TelORB Manager:
    Click the "Refresh" button to update the "Zone State" value.

 4. Verify that "Zone State" is "Idle".
    If "Zone State" is not "Idle", the system is busy with something else that
    must finish before the disable/enable operations further down in these
    instructions can be accepted. In this case, wait for "Zone State" to become
    "Idle".

 5. Check the status of the processor to be replaced, by performing the
    following in the "Processors" card in the TelORB Manager:
    - Click "Rescan" to update the upper processor list.
    - Click the processor to be replaced.
    - Check if the processor is already disabled, i.e. if the "Status" of the
      processor is "Out of Service". (If so, the processor should be red-
      marked in the upper processor list and the alarm "Processor
      Disabled" should exist in the alarm log.)

    - If the processor "Status" is "Out of Service", skip to step 8.
    - If the processor "Status" is "In Service", continue below.

 6. This step is only valid for FS and IO.
    Verify that the processor pair is synched by checking that the alarm
    "Processor pair is synching on..." does not exist for the processor to be
    replaced. (This can also be checked in the "Processor HW" card in the
    "Processor Pairs" area in the TelORB Manager, as described in step 21
    below.)

 7. Disable the processor to be replaced, by performing the following in the
    "Processors" card in the TelORB Manager:
    - Click the processor to be replaced (if not already selected).
    - Click "Disable" and answer "Yes" to the popup question.
        Notification: "Disable Processor Started".
    - Wait for the processor to be disabled.
        Notification: "Disable Processor Finished Successfully".
        Alarm: "Processor Disabled".
        Alarm: "Processor pair is synching on...". (Only for FS and IO.)
    - Click "Rescan" to update the upper processor list.
    - Verify that the processor to be replaced is red-marked.
    - Click the processor to be replaced.
    - Verify that the "Status" of the processor is "Out of Service".
    (Note for FS and IO: If the processor to be replaced was Primary, the
    disable operation has forced the other pair processor to take over as
    Primary.)

 8. Physically, disconnect any cables at the front of the processor to be
    replaced, and then disconnect the processor from the magazine.
      Alarm: "Hardware configuration is changed".

 9. In the "Hardware" card in the TelORB Manager:
    - Click "Rescan" to update the Hardware card.
    - Click the Mag <n> tab for the magazine where the disconnected
      processor was located.
    - Verify that the text "(Changed)" is displayed for the disconnected board.

10. Set up a minicom session (or equivalent) as follows:
    - Initiate a minicom session on a serial terminal.
    - In the minicom window, type Ctrl-a z to enter the Minicom configuration
      menu and then adjust the following minicom settings:
      o Terminal settings (T) -> set Backspace key sends (B) to "DEL" -> Enter.
      o Set lineWrap on/off (W) to "Linewrap ON" -> Enter (or wait).

11. The new (replacement) processor should be physically connected as follows
    (special considerations apply):
    - Physically, slide the new processor into the valid slot in the magazine,
      BUT not all the way in.
    - Connect the previously disconnected cables, if any, to its front, i.e.
      before the board is totally inserted in the magazine.
    - Connect the serial terminal to the new processor, i.e. before the board is
      totally inserted in the magazine.
    - Then slide the processor all the way in.
    Proceed with the next step as soon as possible.
    Note: You only have a few seconds to enter the BIOS configuration menu, as
          described in the next step.
          If you miss this time scope, the processor may boot from disk (for IO:
          perhaps with old values or values valid for a different system and
          this may lead to a zone reload. I have issued TR HE99502 for this).
          Therefore, if you miss the scope, immediately reset the processor and
          try to enter the BIOS configuration menu again.

12. Verify that the BIOS Boot Device Priority settings for the new processor
    (using the serial terminal), are set so that it will boot from the internal
    network, as follows (values valid for NSP 4.1 HW) (For NSP 4.0 HW, use
    "LAN 2-1"):
    - During the initial start up sequence of the processor, immediately hit the
      Del button on the serial terminal (and/or Backspace) repeatedly, with the
      cursor in the valid minicom window.
      This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "Boot".
      o In "Boot Settings", select "Boot Device Priority" and press Enter.
      o In "Boot Device Priority", verify that "1st Boot Device" is set to
        "IBA FE Slot 0040 v" (and that "2nd Boot Device" is set to
        "IBA FE Slot 0038 v"?) (and that "3rd Boot Device" is set to
        "Disabled"?). (NSP5.0: IBA GE Slot 0319 v1219 and IBA GE Slot
                                      0318 v1219, respectively)
        If the values are correct, skip to "Select "Exit"." below (or just exit
        the BIOS configuration menu without saving).
        If the values are not correct, just continue.

      o In "Boot Device Priority", select "1st Boot Device" and press Enter.
        A list of available boot options is displayed.
      o Select "IBA FE Slot 0040 v" and press Enter. (NSP5.0: IBA GE Slot
                                                              0319 v1219)
      (o Select "2nd Boot Device" and press Enter.
         A list of available boot options is displayed.)
      (o Select "IBA FE Slot 0038 v" and press Enter.) (NSP5.0: IBA GE Slot
                                                              0318 v1219)
      (o Select "3rd Boot Device" and press Enter.
      (o Select "Disabled" and press Enter.)
      o Press Esc.
      o Select "Exit".
      o In "Exit Options", select "Save Changes and Exit" (default) and press
        Enter.
      o In the opened box "Save configuration changes and exit setup?", select
        "OK", i.e. just press Enter.

13. In the serial terminal window:
    - Wait for the YaST heading "Adding processor to the TSP SiteDb" to appear
      and until "=>  Stage 5: Wait for start signal." has been reached, i.e.
      until the following text is printed:
      "Stage 5, Waiting for installation start notification.".
      (The message "Failed to detect all internal interfaces...", if any, can be
      ignored.)

14. In the "Processor HW" card in the "Processor HW" area in the TelORB Manager:
    - Click "Refresh", to update the processor list. (If the processor was not
      listed at the bottom of the list before it was connected, it will be
      so now.)
    - Click the new processor.
    - Verify that the processor's MAC address, i.e. "hwid", has changed.
    - Click "Set Type". (I have suggested to skip this step, since I find it
                         unnecessary, see TR HF10822)
    - In the opened window, set "Type" to the same value as that of the
      replaced processor, i.e. "TP", "FS" or "IO" and then click "OK".
      The processor will continue to boot.
      Proceed with next step as soon as possible.

15. In the serial terminal window:
    - Wait for the YaST (black) panels to be processed, e.g "Basic
      Installation".
      Do not reply to any questions, i.e. no manual interaction is required.
      The printouts "No bios found at..." and "v_bios: No such file or
      directory", if any, are normal and should not be acted upon.
    If the "Set Type" value was set to "IO", proceed with step 16 as soon as
    possible.
    If the "Set Type" value was set to "TP" or "FS", proceed with step 17 as
    soon as possible.

16. This step is only valid for IO.
    Change the BIOS settings for the new processor (using the serial terminal),
    so that it will load from disk as follows:
      After the YaST panels have been processed, during the initial start up
      sequence of the processor, immediately hit the Del button on the serial
      terminal (and/or Backspace) repeatedly, with the cursor in the valid
      minicom window.
      This will take you to the BIOS configuration menu. If you miss to enter
      the BIOS configuration menu, just press the valid processor's reset
      button and try to enter the BIOS configuration menu once more. (???)
    - Perform the following in the BIOS configuration menu:
      o Select "Boot".
      o In "Boot Settings", select "Boot Device Priority" and press Enter.
      o In "Boot Device Priority", select "1st Boot Device" and press Enter.
        A list of available boot options is displayed.
      o Select "SM-FUJITSU MHT2040" (NSP5.0: #20 ID00 LUN0 FUJITSU MAP3147NP)
        or equivalent and press Enter.
      (o Select "2nd Boot Device" and press Enter.
         A list of available boot options is displayed.)
      (o Select "Disabled" and press Enter.)
      o Press Esc.
      o Select "Exit".
      o In "Exit Options", select "Save Changes and Exit" (default) and press
        Enter.
      o In the opened box "Save configuration changes and exit setup?", select
        "OK", i.e. just press Enter.
    Proceed with the next step as soon as possible.

17. Enable the new processor, by performing the following in the "Processors"
    card in the TelORB Manager:
    - Click "Rescan" to update the upper processor list.
    - Click the new (still red-marked) processor.
    - Click "Enable" and answer "Yes" to the popup question.
        Notification: "Enable Processor Started".

18. Wait for the processor to be enabled.
      Notification: "Enable Processor Finished Successfully".
      Alarm cleared: "Processor Disabled".

19. In the "Processors" card in the TelORB Manager:
    - Click "Rescan" to update the upper processor list.
    - Verify that the new processor is green-marked.
    - Click the new processor.
    - Verify that the "Status" of the new processor is "In Service".

20. In the "Hardware" card in the TelORB Manager:
    - Click "Rescan" to update the Hardware card.
    - Click the Mag <n> tab for the magazine where the new processor is
      located.
    - Click the new processor (with the "(Changed)" text on it).
    - Verify the information in the Card Information area and then click
      "Approve Change".
      (The "(Changed)" text immediately disappears.)
        Alarm cleared: "Hardware configuration is changed".

21. This step is only valid for FS and IO.
    Wait for the processor pair synching process to finalize.
    This is indicated with that the alarm "Processor pair is synching on..."
    for the valid processor is cleared.
      Alarm cleared: "Processor pair is synching on...".
    (You can also monitor the processor pair data and synching progress by
    performing the following in the "Processor HW" card in the "Processor Pairs"
    area in the TelORB Manager:
    - If the heading of the lower area of the "Processor HW" card is
      "Processor Pairs", click "Dynamic Pair Info >>".
    - In the "Processor Pairs Dynamic" area, click "Refresh Pairs List Dynamic".
    - Click the "pair id" in which the new processor is a member and check the
      "percentage synched" value in the "Details" list.
    - Continously, click "Refresh Pairs List Dynamic" and click the same
      "pair id" as before, to verify that the "percentage synched" value
      continues to increase all the way up to 100%.
      When it has reached 100%, the synching is finished and the alarm will be
      cleared.)

The replacing processor procedure is now completed and the new processor should
be in service.

It is not necessary to create a backup, since only the MAC-address fields
(<tsp:hwid> and <tsp:macaddress>) for the replaced processor has
been changed in the Site Database file (/opt/telorb/axe/adm/etc/dbfile.xml on
IO).

(Updated: 2004-12-03)

The Disk Database (DDB) functionality was introduced in TSP 5.1, where:

- Two processors with disk (PMDs) are used as a redundant relational disk
  database for the use by one or several applications. One of the processors
  is acting as primary and the other as standby. If the primary Disk Database
  processor falls over, no database transactions should be lost.
  (TSP already contains a database called DBN and some of the differences from
  the Disk Database are as follows:
  o DBN: Object-oriented, diskless, in-memory, high-performance database
         optimized for telecom applications.
  o DDB: Relational (i.e. not object-oriented) disk-based, provides the
         industry standard SQL language interface for database manipulations.)

- Initially, the Disk Database may only be used on NSP 5.0 hardware.

- The Disk Database processors are included in the CW/OS cluster.

- Only a Linux configured processor can take the role of a Disk Database
  processor.

- No "ordinary" traffic should execute on the Disk Database processors, i.e.
  they are only to be used for Disk Database purposes and should be configured
  (pool allocated) as such.

- Only one Disk Database can be used in the system, i.e. only two PMDs may be
  used for this purpose.

- Several applications can share one Disk Database, by usage of differrent
  "tables".

- To generate Disk DataBase transactions, to e.g. verify the Disk Database
  functionality, use Keyhan Hadjari's Disk DataBase test application.
  Ask him for details.

(Updated: 2005-01-25)

Tidy up the information below!!!

Scenario
--------
Zone 1 (Primary): Netshared mode   Zone 2 (Standby): Netshared mode
Zone 1: Traffic execution, IP address published *.
Zone 2: Yellow load, no backlog, IP address not published

- Disconnect the NetRed links between Zones 1 and 2.

Zone 1: Netshared mode   Zone 2: Netshared mode
Zone 1: Traffic execution, IP address published *
Zone 2: No yellow load, IP address not published
Zone 1 alarms: Connection lost to peer zone
Zone 2 alarms: Connection lost to peer zone

- Disconnect the VIP (traffic) links to Zone 1 => Automatic TakeOver by Zone 2.
                                               => Data loss 1 !!!

Zone 1: Netshared mode   Zone 2: TakeOver mode           (Same modes as when
Zone 2: Traffic execution, IP address published *         disconnecting VIP
Zone 1: No yellow load, IP address also published *       to Zone 2, TC 620)
Zone 1 alarm:  Route to peer zone not available
Zone 2 alarms: Route to peer zone not available
               Takeover from peer zone

- Reconnect the NetRed links between Zones 1 and 2 => Automatic TakeOver by Zone
  1.                                               => Data loss 2 !!!
                                           This data loss may be prohibited by
                                           synching up Zone 1 before performing
                                           the TakeOver.
Zone 1: TakeOver mode   Zone 2: Down mode
Zone 1: No traffic execution, since the VIP links are still disconnected,
        IP address published *
Zone 2: No yellow load, IP address not published
Zone 1 alarm: Takeover from peer zone
Zone 2 alarm: Reconciliation Needed
Zone 1: Number of failed transactions relative peer zone 2 is: -1
Zone 2: Number of failed transactions relative peer zone 1 is: 0

- Reconnect the VIP links to Zone 1.

Zone 1: TakeOver mode   Zone 2: Down mode
Zone 1: Traffic execution, IP address published *
Zone 2: No yellow load, IP address not published
Zone 1: Number of failed transactions relative peer zone 2 is: -1
Zone 2: Number of failed transactions relative peer zone 1 is: 0

- Manual Start Reconciliation in Zone 2. Successful, but no automatic
  GiveBack due to, backlog.

Zone 1: TakeOver mode   Zone 2: Down mode
Zone 1: Traffic execution, IP address published *
Zone 2: Yellow load, backlog, IP address not published
Zone 2: Alarm: Out of sync  (Before external sync started)
Zone 1: Number of failed transactions relative peer zone 2 is: -1
Zone 2: Number of failed transactions relative peer zone 1 is: 1217051
Zone 2: Notification External Sync Succeeded, but still backlog and
        Out of Sync alarm.
        InstalledObjects: -26811554
        UpdatedObjects: 0

- Manual Remote sync from Zone 1. Successful, but still backlog.

Zone 1: TakeOver mode   Zone 2: Down mode
Zone 1: Traffic execution, IP address published *
Zone 2: Yellow load, backlog, IP address not published
Zone 2: Alarm: Out of sync
Zone 1: Number of failed transactions relative peer zone 2 is: -1
Zone 2: Number of failed transactions relative peer zone 1 is: 611340
Zone 2: Notification External Sync Succeeded, but still backlog and
        Out of Sync alarm.
        InstalledObjects: -39186544
        UpdatedObjects: 347086

- Manual Remote sync from Zone 1. Successful, no backlog.

Zone 1: TakeOver mode   Zone 2: Down mode
Zone 1: Traffic execution, IP address published *
Zone 2: Yellow load, no backlog, IP address not published
Zone 2: Alarm: Out of sync cleared
Zone 1: Number of failed transactions relative peer zone 2 is: -1
Zone 2: Number of failed transactions relative peer zone 1 is: 0
Zone 2: Notification External Sync Succeeded.
        InstalledObjects: -1456212
        UpdatedObjects: 309724
Zone 1 alarm:  Takeover from peer zone (still present - OK)

- Manual GiveBack in Zone 1.

Zone 1: Netshared mode   Zone 2: Netshared mode
Zone 1: Traffic execution, IP address published *
Zone 2: Yellow load, no backlog, IP address not published
Zone 1: Number of failed transactions relative peer zone 2 is: 0
Zone 2: Number of failed transactions relative peer zone 1 is: 0
Zone 1 alarm cleared:  Takeover from peer zone

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

TR HF47492!!!

LSV5, wp011: No automatic TakeOver at VIP link loss (IP NetRed)

This TR is related to test case 590 in TSP 5.1 WP011.
The main activities in test case 590 are:
  Disconnect all VIP links to Zone 1.
  Reconnect all VIP links to Zone 1.

When executing the test case, the operator must perform a manual
TakeOver (described in Scenario below) after all VIP links to the
acting primary zone have been disconnected.
In my opinion, the TakeOver should be performed autmatically
by the system.
For details, see Scenario below.

Scenario
--------
Zone 1 (Primary): Netshared mode   Zone 2 (Standby): Netshared mode
Zone 1: Traffic execution, IP address published *
Zone 2: Yellow load, no backlog, IP address not published

- Disconnect the VIP (traffic) links to Zone 1.

Zone 1: Netshared mode   Zone 2: Netshared mode
Zone 1: No traffic execution, IP address published *
Zone 2: No traffic execution, IP address not published
Zone 1 alarm:  Route to peer zone not available
Zone 2 alarm: Route to peer zone not available

The traffic does not automatically start executing in Zone 2!!!

- Manual Smooth TakeOver (to get the traffic to start executing in Zone 2).

Zone 1: Down mode   Zone 2: TakeOver mode
Zone 1: Yellow load, no backlog, IP address not published
Zone 2: Traffic execution, IP address published *
Zone 2 alarm: Takeover from peer zone
Zone 1: Number of failed transactions relative peer zone 2 is: 0
Zone 2: Number of failed transactions relative peer zone 1 is: -1

- Reconnect the VIP (traffic) links to Zone 1.

Zone 1: Down mode   Zone 2: TakeOver mode
Zone 1: Yellow load, no backlog, IP address not published
Zone 2: Traffic execution, IP address published *
Zone 1 alarm cleared:  Route to peer zone not available
Zone 2 alarm cleared: Route to peer zone not available
Zone 1: Number of failed transactions relative peer zone 2 is: 0
Zone 2: Number of failed transactions relative peer zone 1 is: -1

- Manual GiveBack in Zone 2.

Zone 1: Netshared mode   Zone 2: Netshared mode
Zone 1: Traffic execution, IP address published *
Zone 2: Yellow load, no backlog, IP address not published
Zone 1: Number of failed transactions relative peer zone 2 is: 0
Zone 2: Number of failed transactions relative peer zone 1 is: 0
Zone 1 alarm cleared:  Takeover from peer zone


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

TR HF47xxx!!!

LSV5, wp011: Transf Mgr not registered after ZR of peer zone

No registered Transfer Manager in own zone after zone reload
of peer zone (NetRed).

This TR is related to test case 270 in TSP 5.1 WP011.
The main activities in test case 270 are:
  Zone Reload in Primary.
  Reconciliation Successful (normal).

When the test case was executed, the zone reload in the Primary zone resulted
in that both Transfer Managers in the peer zone no longer were registered,
which in turn lead to that the automatic reconciliation just stopped (because
of that the newly created backup was not being transferred to the Primary zone).
For details, see Scenario below.

Scenario
--------
Zone 1: Netshared mode   Zone 2: Netshared mode
Zone 1: Traffic execution, IP address published *
Zone 2: Yellow load, no backlog, IP address not published
Zone 1: Number of failed transactions relative peer zone 2 is: 0
Zone 2: Number of failed transactions relative peer zone 1 is: 0

- Zone reload of Zone 1 initiated from TelORB Manager.

Zone 1: Reloading
Zone 2: 100% green load in all 4 Linux processors.
        Quite soon after the zone reload started:
        0% load in Proc_m0_s1 and Proc_m1_s5 (no traffic pools on these)
        and Dicos loaders.
        ~32% green load in the rest of the processors.
Zone 2 alarm: Takeover from peer zone
Zone 1: Reload OK (one of the IOs performed one extra load, but finally
                   the zone came up)
Zone 1 alarms: Zone Reloaded From Backup  (2005-01-18  16.18:10)
               Out of sync   (2005-01-18  16.19:10)
Zone 2 notifications: 
 NOTIFICATION 20: Reconciliation Started as Primary:     2005-01-18 16:18:23
 NOTIFICATION 21: Backup Started:        2005-01-18 16:18:25
 NOTIFICATION 22: Backup Finished Successfully:  2005-01-18 16:20:13
 NOTIFICATION 23: Capsule Abortion:      2005-01-18 16:53:54 (De2SubPT)
 NOTIFICATION 24: Capsule Abortion:      2005-01-18 16:53:55 (De2SubPT)
 NOTIFICATION 25: Processor Reload Started:  2005-01-18 16:53:55 (Proc_m1_s23)
                                             (JVM crash)
 NOTIFICATION 26: Application Log Messages Lost: 2005-01-18 16:55:31
 NOTIFICATION 27: Processor Reload Finished Successfully:    2005-01-18 16:55:50
 NOTIFICATION 28: Planned Reconfiguration Started:       2005-01-18 16:55:50
 NOTIFICATION 29: unrecognised:  2005-01-18 16:55:50
 NOTIFICATION 30: Planned Reconfiguration Finished Successfully: 2005-01-18
                  16:56:05
 NOTIFICATION 31: Capsule Abortion:      2005-01-18 18:11:31 (De2SubPT)

Zone 1 notifications: None. (One strange thing was that no notifications were
                      received in Zone 1, until I finally got the reconciliation
                      to succeed.)
Zone 1: Number of failed transactions relative peer zone 2 is: 1460478
Zone 2: Number of failed transactions relative peer zone 1 is: -1

- Tried to start a reconciliation from Zone 1, but this resulted in
  "Error starting reconciliation relative to zone 2"!!

I had now entered the unpleasant NetRed lockup situation!!

- Performed a forced TakeOver in Zone 2, which already was in TakeOver mode,
  to get out of the NetRed lockup situation.

- Zone 2 notification: Reconciliation Failed as Primary

- Tried to start a reconciliation from Zone 1, but this still resulted in
  "Error starting reconciliation relative to zone 2"!!

- Started an external sync using a fake backup, i.e. a backup which does not
  exist, in the zone which has its mode set to Down as follows:
    - Clicked Extern Sync in the TelORB Manager's Loadable Extras card for
      NetRed.
    - Entered the Zone Id of the remote zone.
    - Entered a fake Backup path, e.g.
      loadingGroup01_1/backups/Gurka/databaseBackup.
    - Clicked OK. => "System error : Failed to External Synch".

- Tried to start a reconciliation from Zone 1, but this still resulted in
  "Error starting reconciliation relative to zone 2"!!

LOG_WARNING: NRC: DnrcController::Transition to StartReconciliation denied for
peer zone 2 while in state ReadyToReconcileClient

- Zone reload in Zone 1.    =>   Proc_m1_s17 (Linux with Transfer Manager)
                                 reloaded in Zone 2!!!!!

    IO2 came up, but quite soon afterwards it reloaded again.
    Zone 1 up and running.

Zone 1:

$ /> cat NetRed/NRC 

NRC Id: OU/D25 
NRC Version: R50L02

Current state relative peer zone 2 is: ReadyToReconcileClient 

Mode relative peer zone 2 is: Down 

Time stamps (UTC) for partition [1.2] 
         commitByMe: 2005-01-18_12:29:32 
         peerIncludedTo: 2005-01-17_10:29:58 
         ack: 2005-01-18_12:11:55 

Db state for partition [1.2] is: 4

Time stamps (UTC) for partition [2.1] 
         commitByMe: 2005-01-18_12:29:32 
         peerIncludedTo: 2005-01-17_12:11:07 
         ack: 2005-01-18_12:11:55 

Db state for partition [2.1] is: 4

Netshared data cleared (TRUE/FALSE): TRUE 

Number of failed transactions relative peer zone 2 is: 930488 

Link to peer is working (TRUE/FALSE): TRUE 

NRC Heartbeat to peer is working (TRUE/FALSE): TRUE 

DnrcMirrorTailDelay = 500 [ms]

Time stamp for latest backup = 2005-01-18_12:37:48 


Zone 2:

$ /> cat /NetRed/NRC                               

NRC Id: OU/D25 
NRC Version: R50L02

Current state relative peer zone 1 is: ServerReconcileFinished 

Mode relative peer zone 1 is: Takeover 

Time stamps (UTC) for partition [2.1] 
         commitByMe: 2005-01-19_11:28:54 
         peerIncludedTo: 2005-01-18_12:37:48 
         ack: 2005-01-15_13:24:21 

Db state for partition [2.1] is: 0

Time stamps (UTC) for partition [1.2] 
         commitByMe: 2005-01-19_11:28:54 
         peerIncludedTo: 2005-01-18_12:37:48 
         ack: 2005-01-15_13:24:21 

Db state for partition [1.2] is: 0

Netshared data cleared (TRUE/FALSE): FALSE 

Number of failed transactions relative peer zone 1 is: -1 

Link to peer is working (TRUE/FALSE): TRUE 

NRC Heartbeat to peer is working (TRUE/FALSE): TRUE 

DnrcMirrorTailDelay = 500 [ms]

Time stamp for latest backup = 2005-01-19_11:28:56 

- Performed the same steps as described above and additionally I got
  uabsung's help to restart both Transfer Manager processes (on the
  Linux processors).

- The reconciliations now worked fine, but one more remote sync was
  required to get rid of the backlog.

- Giveback => OK.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

When ending up in a NetRed lockup situation, e.g. when it is not possible to
start reconciliation (Error starting reconciliation relative to zone 2) do as
follows:
  Either perform a forced TakeOver in the zone which has its mode already set
  to TakeOver. This usually releases the lockup.

  If this does not release the lockup, start an external sync using a fake
  backup, i.e. a backup which does not exist, in the zone which has its mode
  set to Down as follows:
    - Click Extern Sync in the TelORB Manager's Loadable Extras card for NetRed.
    - Enter the Zone Id of the remote zone.
    - Enter a fake Backup path, e.g.
      loadingGroup01_1/backups/Gurka/databaseBackup
    - Click OK. => "System error : Failed to External Synch".

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Printouts received when NetRed link is disconnected:

  Network Redundancy link shut down ...No Heartbeats for (secs): 6000
  LOG_ERR: PpClient: Network Redundancy link shut down ...No Heartbeats for
  (secs): 6000

Printouts received when NetRed link glitches (Search for e.g. RECV):
  LOG_ERR: ClientTcpPort.cc:441 [OU/D18 R50L01] RECV failed (0), connection lost

(Updated: 2004-06-09)

These instructions are kept for reference reasons, but should not be followed!

Configure VIP
-------------
This example of configuring VIP shows how to do it on TelORB system to28.
Adjust IP addresses and other parameters to suit your system.

VIP address to to28: 134.138.71.28   (Currently 172.30.14.28)

- Add eth2 (fxp0) and eth3 (fxp1) on the VIP processors Proc_m0_s17 (Dicos)
  and Proc_m0_s19 (Dicos) in the file /opt/telorb/etc/TspSiteDb.xml:

      <tsp:Processor>
        <tsp:hwid>0,17</tsp:hwid>
        <tsp:name>Proc_m0_s17</tsp:name>
        <tsp:type>Dicos-TP</tsp:type>
        <tsp:position>0,17</tsp:position>
        <tsp:Interfaces>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:a0:a5:50:01:59</tsp:macaddress>
            <tsp:name>eth0</tsp:name>
            <tsp:in_addr>172.16.16.17</tsp:in_addr>
          </tsp:EthernetInterface>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:a0:a5:50:01:5a</tsp:macaddress>
            <tsp:name>eth1</tsp:name>
            <tsp:in_addr>172.16.24.17</tsp:in_addr>
          </tsp:EthernetInterface>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:80:37:8f:34:88</tsp:macaddress>
            <tsp:name>eth2</tsp:name>
            <tsp:in_addr>192.168.76.80</tsp:in_addr>
          </tsp:EthernetInterface>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:80:37:8f:34:89</tsp:macaddress>
            <tsp:name>eth3</tsp:name>
            <tsp:in_addr>192.168.77.80</tsp:in_addr>
          </tsp:EthernetInterface>
        </tsp:Interfaces>
        <tsp:CPUs/>
        <tsp:Devices/>
        <tsp:DiskPartitions/>
      </tsp:Processor>
      <tsp:Processor>
        <tsp:hwid>0,19</tsp:hwid>
        <tsp:name>Proc_m0_s19</tsp:name>
        <tsp:type>Dicos-TP</tsp:type>
        <tsp:position>0,19</tsp:position>
        <tsp:Interfaces>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:a0:a5:50:01:db</tsp:macaddress>
            <tsp:name>eth0</tsp:name>
            <tsp:in_addr>172.16.16.19</tsp:in_addr>
          </tsp:EthernetInterface>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:a0:a5:50:01:dc</tsp:macaddress>
            <tsp:name>eth1</tsp:name>
            <tsp:in_addr>172.16.24.19</tsp:in_addr>
          </tsp:EthernetInterface>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:80:37:8f:34:26</tsp:macaddress>
            <tsp:name>eth2</tsp:name>
            <tsp:in_addr>192.168.76.81</tsp:in_addr>
          </tsp:EthernetInterface>
          <tsp:EthernetInterface>
            <tsp:macaddress>00:80:37:8f:34:27</tsp:macaddress>
            <tsp:name>eth3</tsp:name>
            <tsp:in_addr>192.168.77.81</tsp:in_addr>
          </tsp:EthernetInterface>
        </tsp:Interfaces>
        <tsp:CPUs/>
        <tsp:Devices/>
        <tsp:DiskPartitions/>
      </tsp:Processor>

- Stop and start TelORB services to activate the new settings.

- Modify the epct file as follows:

  - Verify which fxp numbers (and names) that should be used, by checking the
    TelORB console logs at initial load or reload.

  - In the i4ddCommand_300, substitute eth2 with e.g. fxp0 and eth3 with e.g.
    fxp1 (use the findings from the previous step), e.g.:

i4ddCommand_300 = "ddconfig i4dd0 Proc_m0_s17:fxp0:192.168.76.1 Proc_m0_s17:fxp1:192.168.77.2 Proc_m0_s19:fxp0:192.168.76.2 Proc_m0_s19:fxp1:192.168.77.1"


  - Substitute DorbIIOPHostName with DorbExternalIIOPHostName and set
    DorbExternalIIOPHostName to the system's VIP address, e.g.:

# Initial Data Parameter for CORBA/IIOP
# =====================================
DorbExternalIIOPHostName = "134.138.71.28"
#DorbIIOPHostName = "172.16.16.9:172.16.24.137"	# IP addresses of IIOP
						# gateway agents for
						# the system.
						# Use IP address of the
						# first Dicos loader
						# in Network A and IP
						# address of the second
						# Dicos loader in
						# Network B in own zone.


- Verify that the system's VIP address works:
  - Log in to VIP router 1: ssh telorb@134.138.71.2
  - Check connected systems: netstat -rn
    You should be able to see your system's VIP address.

  - Open a shell from your work station and try to ping the VIP address, e.g.:
      /usr/sbin/ping 134.138.71.28


- Start TelORB Manager and TelORB processor load viewer (win) on e.g. tos1/tos2
  (your build environment) using the TelORB system's VIP address:

  - Source valid testbed, e.g.:
      source /ipims_dicos/BS2/tbAD15/IP_CONF_INFO/EnvSettings

  - Source valid test environment, e.g.:
      source /ipims_dicos/BS2/tbTEST15.0/IP_CONF_INFO/EnvSettings

  - Set environment variable DISPLAY if e.g. xclock does not work:
      setenv DISPLAY 134.138.186.xx:0.0 (Adjust IP address to your work station)

  - Start and connect the TelORB Manager:
      TelORBManager -alarms &

      Connect: to28 or VIP address (e.g. 134.138.71.28 to to28)

  - Start TelORB processor load viewer (win):
      win -th to28 -ns&

  Note: When I used tos2, no alarms nor notifications were received, but this
        worked when I used tos1.

(Updated: 2004-01-19)

Problem
-------
"Corba communication problem: Contact ORB administrator" popup when trying to
connect the TelORB Manager.

Solution
--------
There is a new version of OpenORB ( 1.3.1 over 1.2.1 ) which affected the
TelORB Manager.
This problem apears either because of an OpenORB compatibility problem or
someone mixed with the DorbIIOPHostName variable.

Anyway, this problem can be fixed this way:

* First of all, *always* remove the DorbIIOPHostName variable from initial data.

* If you use VIP, set the DorbExternalIIOPHostName to the VIP address.
  In this case, you can use either of all three adresses (VIP + loaders) to log
  in.

* If you don't use VIP, but have access to routers, set the
  DorbExternalIIOPHostName to the address of *only one* of your loaders.
  In this case, you can use one of loader addresses to log in.

*  If you don't use VIP and have no router, set the DorbExternalIIOPHostName to
   the  address of *only one* of your loaders.
   In this case, you can only log in by using the adress of the
   DorbExternalIIOPHostName.

Note that all customers will only use VIP for this purpose.

(Source: E-mail from Babbis Xagorarakis, 2004-02-19, slightly modified by Michel)

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Problem
-------
IP-server locations.

Solution
--------
Until further notice, in mixed systems, the IP servers should be located on
Dicos processors. This is specified as follows in the epct file:

INITIAL DATA
//IPV4
ipUnitCommand_1 = "[1018675], 256, 256, [Processor1, Processor2....]"
ENDDATA

All Dicos processors should be specified within the last brackets. 

(Source: E-mail from Magnus Engberg, 2004-02-20, translated by Michel)

HAFS and IOs in cluster (Copied from Andreas Johansson, 2004-05-13)

HAFS
################################################################################
################################################################################
################################################################################

 Check if cyncing and also status
 ########################################
 cat /proc/drbd		


 Change the bandwith when sync, in runtime
 ########################################

 *
 su (on primary)

 *
 drbdsetup /dev/nb0 syncer --max 10000    # Default


Change the bandwith when sync, default setting
########################################

*
su (on both IOs)

*    
vi /etc/init.d/drbdConfig

Change: sync-rate=10000 



 Deactivate TSP om IOs
 ################################################################################
 ################################################################################
 ################################################################################

 Make the IO not to start the TSP part when reloading
 ########################################
 *
 su root

 *
 insserv -rf tsp.init

 *
 Restart the IO
 The IO should start without the TSP part
 (insserv -f tsp.init) set it back to normal


 Stop and start the TSP on IO
 ########################################
 *
 su root

 *
 /etc/init.d/tsp.init stop

 *
 /etc/init.d/tsp.init start



Build stuff
################################################################################
################################################################################
################################################################################

Go to the distribution
########################################
cd /opt/telorb/axe/runtimes/


Go to the epct files, this only exist on IO2
########################################
cd /var/opt/tsp/epct/	


Source the distribution on the IO, as telorb
########################################
/opt/telorb/bin/eprtsetup


Source the distribution on the UAB environment
########################################
tcsh
cd /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/TelORB-R15-LSV509A/TelORB-R15-LSV509A-Runtime/
source setup.csh
cd /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/TelORB-R15-LSV509A/TelORB-R15-LSV509A-SDK/
source setup.csh

cd /var/opt/tsp/epct/


Source tbAD15.2
########################################
tcsh
source /ipims_dicos/BS2/tbAD15.2/IP_CONF_INFO/EnvSettings > /tmp/result


Source tbAD15.1-pre
########################################
tcsh
source /ipims_dicos/BS2/tbAD15.1-pre/IP_CONF_INFO/EnvSettings > /tmp/result


Source tbTEST15.0
########################################
tcsh
source /ipims_dicos/BS2/tbTEST15.0-LSV509A/IP_CONF_INFO/EnvSettings > /tmp/result (no result)


LSV508.2 TLMs
########################################
epconfig d -a
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/upgrades > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE55734_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/hwtrap > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE58445_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE59524_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE59255_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE59518_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE59088_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE61507_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE59909_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508.2/HE60300_1 > /tmp/result

LSV508 TLMs
########################################
epconfig d -a
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508/HE59121_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508/HE66300_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508/HE67431_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508/HE59524_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508/HE59088_0 > /tmp/result
epconfig s -r /ipims_dicos/ipims_dicos10/dists/TSP5.0-patch/troubleshooting/TLMsForLSV508/HE65981_0 > /tmp/result


Special epconfig
########################################

# Görans crashcollector
epconfig s /home/dicoshack/Hack/uabgros/work/HE65978/CrashCollectorRpm_LM  > /tmp/result


Original build command executed by the wizard
########################################
epct -v -c -F -f loadingGroup01_1 -d /opt/mirror /var/opt/tsp/epct/E00NodeType.epct /var/opt/tsp/epct/E80cwos_initial.epct


Various build commands (as telorb)
########################################
Normaly use the "-d /opt/telorb/axe/" option to point where the write the code.
If, for example, the TSP part is stopped on the IO where the build will be
carried out, use the "-d /opt/mirror" option instead.

# Original epct, build by root and to /opt/mirror, do not use this one
# epct -v -c -F -f loadingGroup01_1 -d /opt/mirror /var/opt/tsp/epct/E00NodeType.epct /var/opt/tsp/epct/E80cwos_initial.epct > /tmp/result

# Build a mixed system with TSP Ref APP
cd /var/opt/tsp/epct
epct -v -c -F -X -f loadingGroup01_1 -d /opt/telorb/axe/ E00NodeType.epct E10cwos_initial.epct E10Name.epct TSPRefApp.epct > /tmp/result


Various upgrade commands (as telorb)
########################################

# Add TLMs
cd /var/opt/tsp/epct
epct -t i486 -v -F -V -X -d /opt/telorb/axe/upgradePackages -u /opt/telorb/axe/loadingGroup01_1/Name_of_the_zone.config E00NodeType.epct E10cwos_initial.epct E10Name.epct TSPRefApp.epct AddTLMName.epct > /tmp/result

# Test LMs
cd /var/opt/tsp/epct
epct -t i486 -v -F -V -X -d /opt/telorb/axe/upgradePackages -u /opt/telorb/axe/loadingGroup01_1/Name_of_the_zone.config E00NodeType.epct E10cwos_initial.epct E10Name.epct TSPRefApp.epct NewName.epct > /tmp/result

# Add TSP Ref App
epct -t i486 -v -F -V -X -d /opt/mirror/upgradePackages -u /opt/mirror/loadingGroup01_1/Name_of_the_zone.config /var/opt/tsp/epct/LinuxOnly.epct /var/opt/tsp/epct/E80cwos_initial.epct /var/opt/tsp/epct/TSPRefApp.epct /var/opt/tsp/epct/newName.epct > /tmp/result

# Smoot upgrade
epct -t i486 -v -F -V -X -d /opt/mirror/upgradePackages -u /opt/mirror/loadingGroup01_1/Name_of_the_zone.config /var/opt/tsp/epct/LinuxOnly.epct /var/opt/tsp/epct/E80cwos_initial.epct /var/opt/tsp/epct/TSPRefApp.epct /var/opt/tsp/epct/newName.epct > /tmp/result

epct -t i486 -v -F -V -X -d /opt/mirror/upgradePackages -u /opt/mirror/upgradePackages/TC_07_003_Upgrade_TelORB_IDP_smooth.config /var/opt/tsp/epct/LinuxOnly.epct /var/opt/tsp/epct/E80cwos_initial.epct /var/opt/tsp/epct/TSPRefApp.epct /var/opt/tsp/epct/newName.epct > /tmp/result



Check the epct command
########################################
less /tmp/result


Needed if the epct was not made by telorb
########################################
chown -R 101:501 /opt/mirror/loadingGroup01_1



Site database
################################################################################
################################################################################
################################################################################

Site database file
########################################
/opt/telorb/axe/adm/etc/dbfile.xml
(/opt/mirror/adm/etc/dbfile.xml) This path should not normally be used.


Remove one processor
########################################
sitedbclient remove Processors THE Processor hwid=00:a0:a5:4c:00:69


Check one processor
########################################
sitedbclient query Processors THE Processor hwid=00:a0:a5:4c:00:69 ??? Fungerar
inte bra för mig


Manually change stuf in the database, should not normally be done
########################################

To edit the site database manually you must be root. NFS will restric what can
be done as root, that is the reason why the file is edited via
"/opt/mirror/adm/etc" on the primary IO.

*
su root (on the primary IO)

*
/etc/init.d/sitedb stop
/etc/init.d/dhcpd stop

*
cp /opt/mirror/adm/etc/dbfile.xml /opt/mirror/adm/etc/orginal.dbfile.xml

*
vi /opt/mirror/adm/etc/dbfile.xml

*
/etc/init.d/sitedb start
(/etc/init.d/dhcpd start) dhcp should be started when the site database is started.



 Consolelogs
 ################################################################################
 ################################################################################
 ################################################################################

 Start STS manually before Total
 ########################################
 /opt/telorb/etc/rc.d/init.d/STSswRpm start	# Start, as root
 /opt/telorb/etc/rc.d/init.d/STSswRpm status	# Status


 Start all console log windows
 ########################################
 The ".config" file must be the one that correspond to the running system,
 othervise can the result be that no consolelogs are showned.

 STS_console --config /opt/telorb/axe/loadingGroup01_1/Name_of_the_zone.config --font 6x10 --max 66



 Mount the UAB environment on the IOs
 ################################################################################
 ################################################################################
 ################################################################################

 *
 su root

 *
 Add the following lines to the end of the file /etc/fstab

 134.138.185.10:/vol/vol3/export/u301/ipims_dicos            /ipims_dicos    nfs     soft,bg,intr,rw
 134.138.185.10:/vol/vol3/export/u306/users/dicoshack        /home/dicoshack nfs     soft,intr,rw
 134.138.185.10:/vol/vol3/export/u307/users/dicostest        /home/dicostest nfs     rsize=4096,wsize=4096,timeo=14,intr,rw
 134.138.185.10:/vol/vol3/export/u305/users/dicosadm         /home/dicosadm  nfs     rsize=4096,wsize=4096,timeo=14,intr,rw
 134.138.185.10:/vol/vol3/export/u308/users/dicosarc         /home/dicosarc  nfs     rw
 134.138.185.10:/vol/vol4/export/u407/users/dicosarc2        /home/dicosarc2 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
 134.138.185.10:/vol/vol3/export/u312/users/dicosarc3        /home/dicosarc3 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
 134.138.185.10:/vol/vol3/export/u313/users/dicosarc4        /home/dicosarc4 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
 134.138.185.10:/vol/vol3/export/u314/users/dicosarc5        /home/dicosarc5 nfs rsize=8192,wsize=8192,timeo=14,intr,rw
 134.138.185.10:/vol/vol3/export/u308/users/telorb           /mnt/home/telorb                nfs     soft,bg,intr,rw

 *
 Backup the file
 cp /etc/fstab /etc/fstab.uab

 * 
 Create directories
 cd /home/
 mkdir dicoshack dicostest dicosadm dicosarc dicosarc2 dicosarc3 dicosarc4 dicosarc5 
 mkdir -p /mnt/home/telorb
 mkdir /ipims_dicos

 *
 Mount all new directories
 mount -av



 Serial interface via utmp05
 ################################################################################
 ################################################################################
 ################################################################################

 *
 ssh utmp05

 *
 su root

 *
 Edit /etc/minirc.xx (where xx is 0 to 15 according to the number of the
 connection plate) if necessary

 # Machine-generated file - use "minicom -s" to change parameters.
 pr port             /dev/ttyR14
 pu baudrate         38400
 pu bits             8
 pu parity           N
 pu stopbits         1
 pu minit            
 pu mreset           
 pu rtscts           No 

 *
 exit

 *
 minicom xx (where xx is 0 to 15 according to the number of the connection plate)



Start Loadviever on IO1 or IO2
################################################################################
################################################################################
################################################################################
win -th 172.16.0.9 -th 172.16.0.137 -ns &


Start TelORB Manager from a terminal where the testbed is sourced
################################################################################
################################################################################
################################################################################
source /ipims_dicos/BS2/tbAD15.1/IP_CONF_INFO/EnvSettings
source /ipims_dicos/BS2/tbTEST15.0/IP_CONF_INFO/EnvSettings (to have TSPRefApp
                                                             stuff in TM)
TelORBManager -alarms &
Connect to the VIP address (134.138.71.29 or to29)




Use serial interface for consolelogs all the time, disable STS
################################################################################
################################################################################
################################################################################

*
su root

*
/etc/init.d/sitedb stop
/etc/init.d/dhcpd stop

*
cp /opt/telorb/axe/adm/etc/dbfile.xml /opt/telorb/axe/adm/etc/orginal.dbfile.xml

*
vi /opt/telorb/axe/adm/etc/dbfile.xml

ta bort följande rader:

      <tsp:InitData>
        <tsp:name>stsconfig</tsp:name>
        <tsp:value>172.16.1.1</tsp:value>
      </tsp:InitData>

*
/etc/init.d/sitedb start
(/etc/init.d/dhcpd start) dhcp should be started when the site database is
started.

*
Restart processor or zone to take the changes into action.



Search in consolelog files
################################################################################
################################################################################
################################################################################
 grep -i dump Proc_m* | grep -v Tftp | grep -v DumpDrv
 grep -i crash Proc_m* | grep -v Collector
 grep -i error Proc_m*
 grep -i fail Proc_m*
 grep -i problem Proc_m*
 grep -i dorela Proc_m*
 grep -i 'version mismatch' Proc_m*
 grep -i SERI Proc_m*

 Temorary comands:
 -----------------
 grep -i dump Proc_m* | grep -v Tftp | grep -v DumpDrv | grep -v Netdump
 grep -i crash Proc_m* | grep -v Collector | grep -v Netdump
 grep -i error Proc_m* | grep -v 'error-code' | grep -v dtt4_error_event | grep -v 'time error' | grep -v SERI | grep -v 2000000
 grep -i fail Proc_m* | grep -v 'error-code' | grep -v 'GEMHWI: ' | grep -v reportNewFault | grep -v sendAndAccept | grep -v updateAlarm | grep -v 'Failed to bind'


Make the top command to work when logged into a linux TP
################################################################################
################################################################################
################################################################################
* 
ssh 172.16.2.21
password
xterm

*
tcsh

*
setenv TERM xterm



 Nice viewer to use on Linux machine
 ################################################################################
 ################################################################################
 ################################################################################

 *
 Copy both files in "/home/uabadas/TelORB/myPrograms/xosview/ " to
"/usr/X11R6/bin" on the Linux pot, as root.

 *
 Start it with "xosview" as telorb.



Installation stuff
################################################################################
################################################################################
################################################################################

Start emacs in a better way in the xterm window
########################################
emacs -fn fixed <file name>


Problem
################################################################################
################################################################################
################################################################################

NFS times out when mount to it
########################################
Do to insert and DNS servers in the file "/etc/resolv.conf" on the IOs. Those
servers will not be reachable during startup of the IOs and some functions, i.e.
NFS will be screwed up and not work properly.



Nytt
################################################################################
################################################################################
################################################################################


Install TCL on IO so gemreset is possible
################################################################################
################################################################################
################################################################################
*
rpm -q -a | grep -i tcl

*
put the follwoing file on the IO:
/home/dicosarc3/archive/devenv4.0/DevEnv_SA/LinuxDistributions_SE/SuseLinuxEnterpriseServer8_OB/UnitedLinux-1.0-i386-CD3_SWI/CD/UnitedLinux/src/tcl-8.4-60.src.rpm



*
su

rpm -v -i tcl-8.4-60.src.rpm


# Stop tsp on io
/etc/init.d/tsp.init stop


installera crashcollector
################################################################################
rpm -Uvh --force CrashCollectorRpm.LM_D314.Code.bestintest.i686-linux


 Rensa consoleloggar
 ################################################################################
 su

 cd /opt/telorb/consolelogs

 /opt/telorb/etc/rc.d/init.d/STSswRpm stop

 rm Proc_m*

 /opt/telorb/etc/rc.d/init.d/STSswRpm start
(Source: File /home/uabadas/TelORB/myHelps/IOInCluster.txt, created by Andreas Johansson)

General
 (Updated: 2005-09-29)

This section describes how to upgrade a TelORB system from TSP 4 to TSP 5 and
may give you some hints if you get stuck.
The instructions below are valid for a stand alone system, i.e. NetRed is not
considered. (NetRed systems should be upgraded by performing maiden
installations of one zone at a time.)
So far, the instructions below only cover the CW/OS part, i.e. NM and SS7 are
not yet considered.

For complete runtime installation instructions of TSP4 RM453 MCP3 (including
installation of Kickstart Server, NM and SS7), consult the document "TSP 4 -
Runtime Installation Instructions, RM453", doc no 1/1531-ANA 901 03/2-3,
rev G.

Shortcut upgrading of Kickstart Server, installation of IO1 and IO2,
loading the TSP4 cluster using TSP4 RM453 MCP3, applying the upgrade
path steps 1-6, and more
 (Updated: 2005-09-29)

General
=======
If the Kickstart Server is already installed with what is valid for TSP4, RM453
MCP3, it may be sufficient to just update e.g. the files IO-KickStart-<version>.tar,
tools.CXP901305.<version>.tar, RedHat-7.1-Upgrade-<version>.tar
on the Kickstart Server. This is described in this section where the TSP4
RM453 MCP3 release is being used as an example.
New items since the last Kickstart Server installation are assumed to be all
the files mentioned above.

If the files mentioned above are already installed on the Kickstart Server, you
do not have to re-install them. In this case, it is enough to make sure that
the valid telorb.conf file is located in directory /opt/OS/ on the Kickstart
Server and that the valid dhcpd.conf file will be executing on the Kickstart
Server. Also ensure that the date and time are valid, and that the IO identity
is set to "1" in the /opt/OS/IO.id file. See below for details.

The Kickstart Server ulinpc52 is being used in the instructions below.

The Linux WS tos2 is being used for building the system and creating upgrade
packages in the instructions below.

Fast links (in work order):
- Preparation
- Installation of Kickstart Server
- Installation of IO1 from Kickstart Server
- Installation of IO2 from IO1
- Installation of optional File Servers (FS) from IO1
- Configuration of IO1 and IO2
- Upgrade GESB/SCB FW
- Configure SSH for telorb user

If only CW/OS software should be used, select:
- Installation and configuration of TSP 4.0 CW/OS Runtime distribution software

or if the complete TSP software (CW/OS, NM and SS7) should be used, select:
- Installation and configuration of TSP 4.0 Runtime distribution software

- Populate and start traffic

The Upgrade Path procedure to go from TSP 4 to TSP 5 is divided into the
following steps (from an CW/OS point of view):

Starting point: TSP 4.0 CM453 MCP3 (tbAD14lp11.5).
- Precondition for step 0.5 - Perform an IO backup NM only, but recommended anyway
- Step 0.5 NM only: Smooth upgrade                  (Maintenance window 1)
- Step 1 CW/OS only: Smooth upgrade                 (Maintenance window 1)
- Step 1 CW/OS, NM & SS7: Smooth upgrade            (Maintenance window 1)
- Step 2 CW/OS only: Redundancy reboot upgrade      (Maintenance window 1)
- Step 2 CW/OS, NM & SS7: Redundancy reboot upgrade (Maintenance window 1)
- Step 3 CW/OS only: IO upgrade                     (Maintenance window 2)
- Step 3 CW/OS, NM & SS7: IO upgrade                (Maintenance window 2)
- Step 4 CW/OS only: Redundancy reboot upgrade      (Maintenance window 3)
- Step 5: Smooth upgrade   (TP cleanup)             (Maintenance window 3)
- Step 6: IO upgrade       (IO cleanup)             (Maintenance window 3)
Ending point: TSP 5.2(?).

Fast links (in work order):
- Back to a step 2 (step 3) backup
- Initial load from step 2
- Build TSP 4 upgrade packages for testing purposes


Preparation
===========
- Prepare a TSP 4 telorb.conf file to be used during the IO processor
  installation from the Kickstart Server. (Not necessary for the actual
  Kickstart Server installation/upgrade.)
    (/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/)

- Prepare a TSP 4 epct file to be used during the build of the TSP system
  (only necessary if just executing the CW/OS parts (no NM or SS7). (Not
  necessary for the actual Kickstart Server installation/upgrade or IO
  processor installation. See further down for instructions.)
    (/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/)

- Fetch and unpack the runtimes for RM453 and MCPs 1-3 to e.g. local Linux PC,
  ~/telorb/TSP4_RMCM453....
  chmod -R 775 TSP-4.0-RM453-2-0/

- In a shell on e.g. local Linux PC (e.g. ulinpc235):
    ssh -X root@ulinpc52   (Log in to Kickstart Server, e.g. ulinpc52)
    Password: Axg561

- On the Kickstart server, check if the following files exist and have versions
  which are valid for the TSP4 release to start off from:
    o IO-KickStart-<version>.tar       (RM453: R1F13)  (RM453 MCP3: R3B01)
    o tools.CXP901305.<version>.tar    (RM453: R1AK01) (RM453 MCP3: R3B01)
    o RedHat-7.1-Upgrade-<version>.tar (RM453: R1B01)  (RM453 MCP3: R1B01)
    ls -l /tmp

   (Not performed:
    cd /opt
    ls -l
    mv TSP-4.0 TSP-4.0.oldX  (Adjust X to valid version))

- If the files do not exist, copy all necessary files to /tmp on the Kickstart
  server (ulinpc52) in another shell on e.g. Linux PC (Adjust file versions):
    cd ~/telorb/TSP4_RMCM453_MCP1/TSP-4.0-CM453-2-1/system/unix
    scp IO-KickStart-R3B01.tar root@ulinpc52:/tmp
    scp tools.CXP901305.R3B01.tar root@ulinpc52:/tmp
    cd ~/telorb/TSP4_RMCM453/TSP-4.0-RM453-2-0/system/unix/
    scp RedHat-7.1-Upgrade-R1B01.tar root@ulinpc52:/tmp

- On the Kickstart server (Previously logged in to as root), untar all copied
  files, if not already done:
    cd /tmp
    ls -lrt

    ls -l /opt/OS/install/
    tar -C /opt -xpf IO-KickStart-R3B01.tar  (or R1F13)
    ls -l /opt/OS/install/

    tar -C /opt -xpf RedHat-7.1-Upgrade-R1B01.tar

    ls -l /opt/OS/tar
    cp -a tools.CXP901305.R3B01.tar /opt/OS/tar/  (or R1AK01)

    cd /opt/OS/tar
    ls -l
    ln -sf tools.CXP901305.R3B01.tar tools.tar  (or R1AK01)
    ls -l

- Make sure the telorb.conf file is valid and thereafter copy it to the
  Kickstart server, e.g.:
    cd /opt/OS
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/r14_linux_nsp5_maxi_zone1.telorb_to14_midi.conf .
    Password: tsP4ever

- Link telorb.conf to the copied telorb.conf file:
    ln -sf r14_linux_nsp5_maxi_zone1.telorb_to14_midi.conf telorb.conf
                                                                 (Adjust r14...)

- Make sure you are executing the valid dhcpd.conf file, i.e. the one valid
  for TSP4:
    cd /etc
    ls -l dhcp*
    diff dhcpd.conf dhcpd.conf.tsp4       (Should be no difference)
      If there is a difference:
        rm dhcpd.conf
        cp dhcpd.conf.tsp4 dhcpd.conf
        ls -l dhcp*
        diff dhcpd.conf dhcpd.conf.tsp4   (Should be no difference)


Installation of Kickstart Server
================================
The following steps are preferably performed in the CW/OS lab, since you will
be asked to insert the two RedHat CDs, so have them prepared.

- Execute the Kickstart Server installation script (this will take approximately
  14 minutes in total):
    (cd /opt/OS/tar)
    /opt/OS/install/ks-install.sh
      Prompt: "Please insert RedHat 7.1, CD 1"
        Physically, insert the requested CD and press Enter/Return. (~5 min)
      Prompt: "Please insert RedHat 7.1, CD 2"
        Physically, insert the requested CD and press Enter/Return. (~5 min)
      Prompt: "Please remove the CD from the drive."
        Physically, remove the CD and press Enter/Return. (~4 min)
      The installation will continue by e.g. applying RedHat 7.1 patches and
      installing RPMs.
      Prompt: "Installation completed.
               The machine will now reboot to activate the new confguration
        Press Enter/Return to reboot the Kickstart Server."

- After the reboot, log in to the Kickstart Server:
    ssh -X root@ulinpc52   (Log in to Kickstart Server)
    Password: Axg561

- Verify date and time:
    date
    If not correct, then:
      date -s "YYYY-MM-DD hh:mm:ss"  (Adjust date and time)

- Make sure the IO identity is set to 1:
    more /opt/OS/IO.id
    If not 1, then:
      echo "1" > /opt/OS/IO.id

- Verify that DHCP is executing:
    /etc/init.d/dhcpd status
      If DHCP is stopped, start it:
        /etc/init.d/dhcpd start

  (- If you have additional network interfaces on your Kickstart Server and have
     DNS set, then you should temorarily change the name of the /etc/resolv.conf
     file to resolv.conf.orig, and then restart the network services on the
     Kickstart Server, as follows:
       mv /etc/resolv.conf /etc/resolv.conf.orig
       /sbin/service network restart)

  (- To ensure that the DHCP server only is used for the network towards the TSP
     cluster (e.g. eth0), execute the following commands:
       /opt/OS/install/update_ks_dhcp_config eth0
       /etc/init.d/dhcpd restart
       /etc/init.d/dhcpd status)


Installation of IO1 from Kickstart Server
=========================================
- Before starting the installation of IO1, IO2 must be halted to avoid
  interference during the IO1 installation.
  To accomplish this, open a new shell, log in to IO2 and halt it:
    ssh -X root@toXXio2  (Adjust toXX to valid TSP system)
    Password: rootroot
    halt
      (Alternatively on IO2:
         /opt/telorb/etc/stop_services
         cd /opt/telorb/axe/loadingGroup01_2
         rm -rf mirrored)

- Physically, connect the KickStart server to the 100BaseTx port on any of the
  right-most SCBs in the TSP cabinet.

- Physically, connect a serial cable with a null modem to IO1.

- Open an xterm window, and from there, start the terminal program, e.g. minicom
  or tip, or use the one of the telnet servers (e.g. tspts03 port 2002) in the
  CW/OS lab, as described here:
     telnet tspts03 2002        (Ctrl-AltGraph-9 (Ctrl-]) to exit)

- Change the BIOS settings for IO1 (by using e.g. tspts, connected
  above), so that it will boot from the internal network, as follows
  (values valid for NSP 4.1 HW) (For NSP 4.0 HW, use the same values as for
  installing from installation server, i.e. "LAN 2-1"):
    - Press the reset button on IO processor 1 and then, immediately, hit Del
      (and/or Backspace) repeatedly on the keyboard, with the cursor in the
      valid tspts window. This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "Boot".
      o In "Boot Settings", select "Boot Device Priority" and press Enter.
      o In "Boot Device Priority", select "1st Boot Device" (default) and press
        Enter. A list of available boot options is displayed.
      o Select "IBA FE Slot 0040 v" and press Enter. (NSP5.0: IBA GE Slot
                                                              0319 v1219)
      o Select "2nd Boot Device" and press Enter.
        A list of available boot options is displayed.
      o Select "IBA FE Slot 0038 v" and press Enter. (NSP5.0: IBA GE Slot
                                                              0318 v1219)
      o Press Esc.
      o Select "Exit".
      o In "Exit Options", select "Save Changes and Exit" (default) and press
        Enter.
      o In the opened box "Save configuration changes and exit setup?", select
        "OK", i.e. just press Enter.

- When exiting the BIOS setup, IO1 will reboot and start loading its software
  from the Kickstart Server.
  This will take approximately 20 minutes.

- Wait for the installation of IO1 to complete.
  When completed, you will see the "Congratulations..." message.

- If you get the following message, during the installation of IO1:
    "Error: /tmp/ks.cfg not found"
  then enter the following commands on the Kickstart Server (ulinpc52):
    mv /etc/resolv.conf /etc/resolv.conf.orig
    /sbin/service network restart
  Thereafter, reboot IO1 again.

- After completion of the IO1 installation, change the BIOS settings for
  IO1 (by using e.g. tspts, connected above), so that it will boot from disk:
    - Press "Enter/Return" in the tspts "Congratulations..." window.
    - Immediately when IO1 starts to reboot, hit Del (and/or Backspace)
      repeatedly on the keyboard, with the cursor in the valid tspts window.
      This will take you to the BIOS configuration menu.
    - Perform the following in the BIOS configuration menu:
      o Select "Boot" -> "Boot Device Priority".
      o Set "1st Boot Device" to "SM-FUJITSU MHT2040"
        (NSP5.0: #20 ID00 LUN0 FUJITSU MAP3147NP) or equivalent.
      o Verify that "2nd Boot Device" is set to "Disabled".
      o Press Esc and then save the changes and exit.

- Physically, disconnect the Kickstart Server from the SCB.

- If you get the following message, repeatedly, during the reboot of IO1:
    "PXE-E51: No DHCP or proxyDHCP offers were received."
  then the BIOS restoration was probably not correctly performed.

- When the reboot of IO1 is completed (two of the last messages are
  "Starting TelorbServices" and "Starting anacron"), press "Enter/Return"
  to get a login prompt and log in (or open a new shell and log in to IO1 from
  there):
    telorb
    Password: tel123orb

*** Start: Michel's additional checkpoints ***

- Verify IO tools version and that all services are running:
    /opt/telorb/etc/status_services

- Verify that the correct KickStart version has been installed
  on the IO processor and also verify the IO processor ID:
    cat /etc/version   (gives the RAM disk version)
      --- Start example printout ---
      KickStart-Name: ks-io-sda.cfg
      KickStart-PN:   ii1OU/D203
      KickStart-Rev:  R1D09            (RM453: R1D09)  (RM453 MCP3: R1E01)
      IOprocessor-ID: io1
      --- End example printout ---
    rpm -q kickstart-tsp
      --- Start example printout ---
      kickstart-tsp-R1D09-1            (RM453: R1D09)  (RM453 MCP3: R1E01)
      --- End example printout ---

  If /etc/version does not show R1D09 for RM453, modify this in the
  /etc/version file, i.e. change e.g. R1E01 to R1D09:
    su
    Password: rootroot
    emacs /etc/version &
    exit

- On the Kickstart Server, as a nice gesture to our TSP5 fellows:
  Stop DHCP on the Kickstart Server, since if a TSP5 system is connected to
  the Kickstart Server and TSP4 DHCP is executing, it may affect the TSP5
  system in a negative way (it may take over the DHCP functionality, depending
  on which DHCP server answers first):
    /etc/init.d/dhcpd stop

*** End: Michel's additional checkpoints ***


Installation of IO2 from IO1
============================
- Make sure the Kickstart Server is disconnected from the system.

- Physically, move the serial connection (tspts) from IO1 to IO2.

- Reset IO2 and change its BIOS to make it boot from the internal network,
  as described for IO1 above.

- When exiting the BIOS setup, IO2 will reboot and start loading its software
  from IO1.
  This will take approximately 20 minutes.

- Wait for the installation of IO2 to complete.
  When completed, you will see the "Congratulations..." message.

- After completion of the IO2 installation, change the BIOS settings for
  IO2 (by using e.g. tspts, connected above), so that it will boot from disk:
    - Press "Enter/Return" in the tspts "Congratulations..." window.
    - Change BIOS to make IO2 boot from disk, as described for IO1 above.

- When the reboot of IO2 is completed (two of the last messages are
  "Starting TelorbServices" and "Starting anacron"), press "Enter/Return"
  to get a login prompt and log in (or open a new shell and log in to IO2 from
  there):
    telorb
    Password: tel123orb

*** Start: Michel's additional checkpoints ***

- Verify IO tools version and that all services are running:
    /opt/telorb/etc/status_services

- Verify that the correct KickStart version has been installed
  on the IO processor and also verify the IO processor ID:
    cat /etc/version   (gives the RAM disk version)
      --- Start example printout ---
      KickStart-Name: ks-io-sda.cfg
      KickStart-PN:   ii1OU/D203
      KickStart-Rev:  R1E01            (RM453: R1D09)  (RM453 MCP3: R1E01)
      IOprocessor-ID: io1
      --- End example printout ---
    rpm -q kickstart-tsp
      --- Start example printout ---
      kickstart-tsp-R1E01-1            (RM453: R1D09)  (RM453 MCP3: R1E01)
      --- End example printout ---

*** End: Michel's additional checkpoints ***


Installation of optional File Servers (FS) from IO1
===================================================
No instructions for this yet.
Consult the official installation instructions document, e.g. "TSP 4 - Runtime
Installation Instructions, RM453", doc no 1/1531-ANA 901 03/2-3, (rev G).


Configuration of IO1 and IO2
============================
- From a new shell, log in to IO1 as telorb user:
    ssh -X telorb@toXXio1  (Adjust toXX to valid TSP system)
    Password: tel123orb

- From a new shell, log in to IO2 as telorb user:
    ssh -X telorb@toXXio2  (Adjust toXX to valid TSP system)
    Password: tel123orb

- If required, change root and telorb passwords on both IO processors:
    su -
    Password: rootroot
    passwd root
    Enter new UNIX password:
    Retype new UNIX password:
    passwd telorb
    Enter new UNIX password:
    Retype new UNIX password:
    exit

- On both IOs, check date and time:
    date
    If not correct, adjust the date and time:
      su
      Password: rootroot
      date -s "YYYY-MM-DD hh:mm:ss"  (Adjust date and time)
      exit


Upgrade GESB/SCB FW
===================
- Upgrade the GESB/SCB loadable software (firmware).
  The GESB/SCB software is contained within the IO tools package.
  To upgrade the GESB/SCB software, perform the following procedure from
  e.g. IO1 as telorb user.
    1. Execute the "ping_all" script to get the IP addresses of the GESBs and
       SCBs (Do not bother if Dicos and/or Linux processors have the status
       "FAILED", i.e. only concentrate on the GESB/SCB printouts):
         /opt/OS/ping_all
    2. Log in to each GESB/SCB and do a restart of the board:
         telnet 172.16.xx.xx
         login: razor
         Password: assar
         OSmon> restart cold
           You should get the following printout within ~30 seconds:
             "Connection closed by foreign host."
           If not, disconnect the board (one by one to keep power in the
           magazine) and reconnect it after approximately 10 seconds.
           Fasten all screws.
           Once the board is reconnected, the new software will automatically
           be downloaded from the IO, i.e. if the software version is not the
           same as the existing software version on the GESB/SCB.
       Repeat for all GESBs/SCBs.
    3. Verify that each GESB/SCB is alive by pinging them (Still concentrate on
       the GESB/SCB printouts):
         /opt/OS/ping_all


Configure SSH for telorb user
=============================
- Configure SSH for telorb user. (The SSH Client (/usr/bin/ssh) is a program
  for connecting to a remore host and executing commands on that host.)
  Generating private and public key pairs is already done, but if there are
  some problems, this can be done manually as described in the valid
  installation instruction.
  However, the copying of keys between IO1 and IO2 has to be done manually, as
  follows:
  - From IO1 (as telorb user), copy telorb's public key to IO2:
      scp /home/telorb/.ssh/id_dsa.pub io2:/home/telorb/.ssh/authorized_keys2
                                                     (or use "/usr/bin/scp ...")
      Password: tel123orb


  - From IO2 (as telorb user), copy telorb's public key to IO1:
      scp /home/telorb/.ssh/id_dsa.pub io1:/home/telorb/.ssh/authorized_keys2
                                                     (or use "/usr/bin/scp ...")
      Password: tel123orb

  - Verify that you can enter each IO, respectively, without having to enter
    the password after the ssh command:
      From IO1:
        ssh io2
        exit
      From IO2:
        ssh io1
        exit


CW/OS or CW/OS, NM and SS7?
---------------------------
If only CW/OS software should be used, continue at:
- Installation and configuration of TSP 4.0 CW/OS Runtime distribution software

or if the complete TSP software (CW/OS, NM and SS7) should be used, continue at:
- Installation and configuration of TSP 4.0 Runtime distribution software


Installation and configuration of TSP 4.0 CW/OS Runtime distribution software
=============================================================================

Note: Only use this section if only CW/OS software should be used, i.e. no
      NM or SS7.

In these instructions, the system will be built outside the IO processors.

Now, it is time to build the loadingGroup01_1 and loadingGroup01_2 and then
upload these to the IOs.

  Log in to e.g. tos2 and perform the following:
    ssh -X telorb@tos2
    Password: tsP4ever
    cd /home/dicostest/tosFiles/to14/upgradepath/initialstart_rm453_ec3
    rm -rf *  (If you previously have built and packed the loadingGroups,
               you may continue by copying the loadingGroups to IO1 and IO2,
               respectively, as instructed further down.)
    cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3

     (Magnus Eriksson's initial load files for to13:
      cd /home/dicoshack/Hack/qmageri/upgradepath/initialstart_to13)

    Fetch epct files, if not already done:
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/r14_linux_to14_tbAD14lp11_5_name.epct .
      Password: tsP4ever
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/r14_linux_nsp5_maxi_zone1_to14_midi.epct .
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/r14_linux_refapp_to14.epct .
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/r14_linux_vip_to14.epct .
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/r14_linux_extra_config_to14.epct .

- To be able to use the same epct file for upgrade package creations later on,
  make sure that
    SOFTWARE IDP/SU1;	// TelorbLinux_IDP, Linux (Optional)
  is stated before
    SOFTWARE IDP/D2;	// NetRed_IDP (Optional)
  in the epct file (r14_linux_nsp5_maxi_zone1_to14_midi.epct).

    Source TSP4 RM453 MCP3:
      source /ipims_dicos/BS2/tbAD14lp11.5/IP_CONF_INFO/EnvSettings
                                                         (including TSP4 RefApp)
      setenv EP_WORKSPACE `pwd`/epws

    Build the loadingGroups:
      epct -d /home/dicostest/tosFiles/to14/upgradepath/initialstart_rm453_ec3 -XvFc -f loadingGroup01_1 -f loadingGroup01_2 r14_linux_to14_tbAD14lp11_5_name.epct r14_linux_nsp5_maxi_zone1_to14_midi.epct r14_linux_refapp_to14.epct r14_linux_vip_to14.epct r14_linux_extra_config_to14.epct

      (Magnus Eriksson's build for to13:
       epct -d /home/dicostest/tosFiles/to13/upgradepath/initialstart_rm453_ec3 -XvFc -f loadingGroup01_1 -f loadingGroup01_2 name.epct telorb.epct r14_linux_refapp.epct r14_linux_vip.epct

    Pack the loadingGroups:
      cd /home/dicostest/tosFiles/to14/upgradepath/initialstart_rm453_ec3
      ls -l 
        The following directories/file should have been created:
        o loadingGroup01_1
        o loadingGroup01_2
        o <name_of_system>.config
      tar zcf lg01_1.tgz loadingGroup01_1
      tar zcf lg01_2.tgz loadingGroup01_2

    Copy the loadingGroups to IO1 and IO2, respectively:
      scp lg01_1.tgz telorb@toXXio1:/opt/telorb/axe/  (Adjust toXX to valid
      Password: tel123orb                              TSP system name)

      scp lg01_2.tgz telorb@toXXio2:/opt/telorb/axe/  (Adjust toXX to valid
      Password: tel123orb                              TSP system name)

On IO1, unpack loadingGroup01_1:
  cd /opt/telorb/axe
  tar zxf lg01_1.tgz

On IO2, unpack loadingGroup01_2:
  cd /opt/telorb/axe
  tar zxf lg01_2.tgz



- On IO1, start the processor console logs:
    Create a start_consoles file below /opt/telorb/consolelogs/ and start it:
      /opt/telorb/consolelogs/start_consoles
        (I have created start_consoles and stop_consoles files for to14, which
         may serve as a templates, and they can be fetched from:
          cd /opt/telorb/consolelogs
          scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/start_consoles .
          scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/stop_consoles .)
    Never mind what the console logs currently display.

- Start the LoadViewer externally or internally
  o Externally, using the VIP address, on e.g. tos2:
      source /ipims_dicos/BS2/tbAD14lp11.5/IP_CONF_INFO/EnvSettings
      win -th 172.30.14.xx -ns & (Adjust VIP address to suit your system)

  o Internally, on IO1:
      /opt/telorb/codearchive/iom_scripts/win -th 172.16.0.9 -th 172.16.8.9 -th 172.16.0.137 -th 172.16.8.137 -ns &

- Physically, reset all traffic processors and make sure the INITIAL Dicos
  loader starts loading before the second Dicos loader.
  Do not reset the IO processors.

- On IO1, verify that all processors have come up and are running (you may also
  verify the loading of each processor by monitoring the processor console
  logs):
    tail -f /opt/telorb/consolelogs/Proc* | grep "Total functionality"
    Ctrl-c

DEBUG INFO: DlgCoVip_TotalImpl::getConfigData there are 0 VIP TGs
DEBUG INFO: DlgCoVip_TotalImpl::getConfigData there are 0 VIP TGs
DEBUG INFO: DlgCoVip_TotalImpl::getConfigData there are 0 VIP TGs
DEBUG INFO: DlgCoVip_TotalImpl::getConfigData there are 0 VIP TGs

- On IO1, verify that all processor and GESB/SCB interfaces are alive by pinging
  them:
    /opt/OS/ping_all

- On IO1, check if there are any error dumps and/or crashcollector files:
    ls -l /opt/telorb/dumps/
    ls -l /opt/telorb/crashcollector/
    If there are any, and they were created before you reset all traffic
    processors, you can remove them. Otherwise, investigate them.

- On e.g. tos2, start TelORB Manager and manually connect it to the system:
    source /ipims_dicos/BS2/tbAD14lp11.5/IP_CONF_INFO/EnvSettings
                                              (Including TSP4 RefApp and Extras)
    TelORBManager -alarms &                   (Version R1AB11 will be opened)
    Connect: 172.30.14.xx

- From the TelORB Manager:
  - Check for any alarms and take necessary actions if undesired alarms are
    found.
  - Create a backup version without populating the database.
  - Populate the database and start TSP RefApp traffic.
      See "SYSTEM CONFIGURATION" below for details.
  - Start VIP traffic.
       Either by using the external VIP traffic generator(s) or from e.g. your
       PC:
         - Source a valid testbed, e.g.:
             source /ipims_dicos/BS2/tbWP046/Setup.csh

         - Start VIP traffic:
             `epgetpath LM/VIP101`/bin/VIPtrafficgenerator.LM_VIP101.R2A02.i486-Redhat-6.0 172.30.14.XX 5987 5988 
  - Create a backup version.


SYSTEM CONFIGURATION
====================
General
-------
Test date:                  October 14, 2005
Tester:                     Michel Sundin

Software data
-------------
Release:                    TSP4, RM453, MCP3
SW source: source  /ipims_dicos/BS2/tbAD14lp11.5/IP_CONF_INFO/EnvSettings
TLMs:                       None
Linux version on IOs:       2.4.19-R1B04 (uname -r)
Linux version on TPs:       2.4.19-R1B05 (uname -r)
Installation CD version:    ??
TelORB Manager version:     R1AB11

Node data
---------
Test node:                  to14
Node type:                  NSP 5.0
SW configuration:           Midi, DicosMax (34 processors used in a maxi system)
Network redundancy:         No
Partitioned NetRed:         No
Total amount of processors: 34
No. of Dicos TP processors: 32
No. of Linux TP processors: 2
No. of Linux IO processors: 2
No. of Linux FS processors: 0
VIP address:                172.30.14.14

TSP Ref App traffic data
------------------------
Pool configuration:         De2SubPool on all Dicos processors.
                            De2SubLinuxPool on all Dicos processors.

POPULATE (Database):        Size of Objects: 666 bytes
                            Ranging from: 0    Ranging to: 8000000
                            Size of Objects: 2666 bytes
                            Ranging from: 8000001    Ranging to: 10000000

Dicos traffic:	
      Internal traffic:
			C++:  CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 20000            (calls/sec)
                              Ranging from: 0    Ranging to: 8000000

			Java: CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 20000             (calls/sec)
                              Ranging from: 0    Ranging to: 8000000

Linux traffic:	
      Internal traffic:
			C++:  CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 70               (calls/sec)
                              Ranging from: 8000001    Ranging to: 10000000

			Java: CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 70               (calls/sec)
                              Ranging from: 8000001    Ranging to: 10000000

      External VIP traffic: None yet!!!
			C++:  CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 500              (calls/sec)
                              Ranging from: 0    Ranging to: 4000000

			Java: CT1:       15 10            (% t)
			      CT2:       15 10 34 33 33   (% t R W C/D) 
			      CT3:       15 30 34 33 33 3 (% t R W C/D reps)
			      CT4:        0 40            (% t)
			      U:         25               (%)
			      R:         20               (%)
			      C/D:       10               (%)
			      OP4:        0 1000 20 10    (% ? ? ?)
			      Intensity: 500              (calls/sec)
                              Ranging from: 0    Ranging to: 4000000

File Server Traffic:    None

External traffic generators: None yet!!!
			134.138.186.235 (Michel's Linuc PC):
/home/dicosarc10/archive/LSV1/cwos-LSVtsp51base-test/system/TelORB/IDP_VIP101_R1A02-VIPtrafficgenerator/included/LM_VIP101-VIPtrafficgenerator/bin/VIPtrafficgenerator.LM_VIP101.R2A02.i486-Redhat-6.0 172.30.14.14 5987 5988

Processor load
--------------
Dicos, Cluster Control:       0%
Dicos, TPs:              ~50-53%
Linux, TPs:              ~36-42%

Processor memory usage (Memory usage, DBN memory usage)
-------------------------------------------------------
Dicos, Cluster Control:          6%, 0%
Dicos, TPs:              54-57%, 58-60%
Linux, TPs:                      3%, 0%

- Continue at Step 1 CW/OS only.


Installation and configuration of TSP 4.0 Runtime distribution software
=======================================================================

Note: Only use this section if the complete TSP software (including CW/OS, NM
      and SS7) should be used.

In these instructions, the system will be built on the IO processors.

- Copy the following runtime files, valid for RM453, from GASK to /home/telorb/
  on IO1 (this time fetched from qperulf's PC ulinpc249 (134.138.186.249)):
    cd /home/telorb
    scp telorb@134.138.186.249:/home/qperulf/data/RM453/1_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz .
    Password: tsP4ever
    scp telorb@134.138.186.249:/home/qperulf/data/RM453/72_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz .

  (Additionally, I also fetched the runtime and MCP files from Ulfs Linux-PC
   ulinpc249 to my PC, as follows:
    On my PC:
      cd /home/uabmsu/telorb/upgradepath_tsp4_to_tsp5/RM453
      - RM453 Runtime, part 1:
          scp telorb@134.138.186.249:/home/qperulf/data/RM453/1_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz .
      - RM453 Runtime, part 2:
          scp telorb@134.138.186.249:/home/qperulf/data/RM453/72_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz .
      - MCP1:
          cd /home/uabmsu/telorb/upgradepath_tsp4_to_tsp5/RM453/MCP1
          scp telorb@134.138.186.249:/home/qperulf/data/RM453/MCP1/113_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz .
      - MCP2:
          cd /home/uabmsu/telorb/upgradepath_tsp4_to_tsp5/RM453/MCP2
          scp telorb@134.138.186.249:/home/qperulf/data/RM453/MCP2/117_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz .
      - MCP3:
          cd /home/uabmsu/telorb/upgradepath_tsp4_to_tsp5/RM453/MCP3
          scp telorb@134.138.186.249:/home/qperulf/data/RM453/MCP3/121_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz .)

- Verify the sizes of the copied files:
    ls -lrt

      1_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz  should be 232285483
      72_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz should be 553878667

- Verify the checksum of the copied files:
    cksum 1_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz
    cksum 72_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz

      1_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz  should be 1300274420
      72_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz should be 585016472

- Create the default file "Node_data.dat" at /home/telorb/ on IO1 as follows:
    I fetched a template from qperulf and modified it to suit to14 (you may also
    use the Node_data.dat.template file to start off with):
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/Node_data.dat .
      Password: tsP4ever

      --- Start example printout for to14 ---
VIP_router_addr = 192.168.76.1:192.168.77.2
DNS_server_address1 = 134.138.201.17
DNS_server_address2 = 134.138.226.13
ext_vip_addr = 172.30.14.14
      --- End example printout for to14 ---

- Extract the runtime distribution files and execute the loadscript1.sh script:
    cd /home/telorb
    gtar xfz 1_19089-LZN9010214_6_EN_G_GTAR_GZIPV1.gtar.gz TSP-4.0-RM453-2-0/config/scripts/loadscript1.sh
    cd TSP-4.0-RM453-2-0/config/scripts
    ./loadscript1.sh
    Password: rootroot
    Will Linux be used? (y/n) y
    Will VIP be used? (y/n) y
    Shall "OSPF area id" be inserted? (y/n) y
    Will /DBN Disk Logging/ be used? (y/n) n
    Will /SS7/ be used? (y/n) y
    Specify the name of the zone, e.g. Stockholm_GSM_UMTS_HLR_R1A.
      Enter the Zone name: to14
    Found default value for "External VIP address":
      172.30.14.14
      Is this address correct?  (y/n) y
    Found default value for "VIP router link addresses":
      192.168.76.1:192.168.77.2
      Are these addresses correct?  (y/n) y
    Found default value for first "DNS_SERVER":
      134.138.201.17
      Is this address correct?  (y/n) y
    Found default value for second "DNS_SERVER"
      134.138.226.13
      Is this address correct?  (y/n) y
    Will "Unique node identity" be used? y/n   n
    * epct parameter fetched
      *  4.1.1.1 Ready
      Are this data correct? y/n?
      HW = NSP5
      Configuration = maxi
      Zone = zone1               n
     Enter the ver. of the node
       1  NSP 4
       2  NSP 5                  2
     Enter the no: for the system type you are installing
       1  Micro        (NSP 5)
       2  Micro 1 mag  (NSP 4)
       3  Micro 4 mag  (NSP 4)
       4  Mini
       5  Midi
       6  Maxi
       7  Opti         (NSP 5)      5
     Enter the no: of the ZONE
       1  Zone 1
       2  Zone 2                    1
    r14_linux_nsp5_midi_zone1.epct.template
      Copy r14_linux_nsp5_midi_zone1.epct.template to /opt/telorb/system
      Copy telorb.epct file
      * r14_linux_nsp5_midi_zone1.epct.template copied
      *  4.1.2 Ready
      * 4.1.3 Select which signaling stack to use
      Choose SS7 stack
      1   ansi
      2   china
      3   itu
      4   itu_hsl
      Enter a directory no. or n to terminate the script       3
    Copy SS7.epct file
      Copy SS7_nsp5_midi_zone1_itu.epct
      * SS7_nsp5_midi_zone1_itu.epct copied
      *  4.1.3 Ready
      * 4.1.3.3 Initiate protocols for itu stack
      Enter the no: for the configuration of the stack you are installing
      1  ITU TCAP on ITU Network
      2  ANSI TCAP on ITU Network
      3  ITU TCAP and ANSI TCAP on ITU Network                 1
    *  4.1.3.3 Ready
      * 4.1.4  Copy NM files
      Copy Node_Mgt_nsp5_midi_zone1.epct
      * Node_Mgt_nsp5_midi_zone1.epct copied
      *  4.1.4 Ready
      *  4.1.5 Copy setup.csh file in IO1
      * setup.csh copied
      *  4.1.5 Ready
      *  4.1.6 Copy and edit win.csh file in IO1 and IO2
      * ssh io2 mkdir -p /opt/telorb/config
      *  4.1.6 Ready
      * 4.1.7  Copy and edit win.csh file in IO1 and IO2
      Copy win.csh from io1 to io2
      win.csh              100% |***********************************************************************|   875       00:00    
      * Copied node type is: midi_zone1_nsp5
      *  4.1.7 Ready
      *  4.1.8 Create .tcshrc file in IO1 and IO2 
      .tcshrc              100% |***********************************************************************|    34       00:00    
      *  4.1.8 Ready
      *  4.1.9 Copy addresses from telorb.conf to telorb.epct
      ******   Copying  data from   ******
      ***  telorb.conf to telorb.epct  ***
      ***     nm.epct and  SS7.epct    ***
      ***  using "conf2epct" ver. 3.4  ***
      Warning There are more processors in SS7.template file than in telorb.conf!
      *  4.1.9 Ready
      *  4.1.10 Write addresses ( VIP, DNS ) to telorb.epct
      *  Remove hash mark for VIP IDP's in telorb.epct file
      *  4.1.10 Ready
      *  4.1.11 Write Symbolic Addresses  for DNS_SERVERS to telorb.epct
      *  4.1.11 Ready
      *  4.1.12 Write node name to telorb.epct
      *  4.1.12 Ready
      *  4.1.13 DBN disk logging will NOT be used 
      *  4.1.14 Linux will be used 
      *  4.1.14 Ready
      *  4.1.15 Write VIP address to nm.epct 
      *  4.1.15 Ready
      *  4.1.16 Write SocketUserDistributionCfg number to SS7.epct
      *  4.1.17 Write VIP address to SS7.epct 
      *  4.1.18 OSPF area code added to telorb.epct 
      *        2887650830 copied to telorb.epct
      *  4.1.18 Ready
      *  4.1.19 Write the externa Vip router addresses to telorb.epct 
      *  4.1.19 Ready
      Edit the epct files (if necessary) and run epct

  The following epct files have now been created on IO1 below
  /opt/telorb/system/:
    nm.epct
    SS7.epct
    telorb.epct

- If you have already prepared all required epct files, fetch them to IO1.
  Otherwise, continue at "First time" further down.

    Log in to IO1 and perform the following:
      ssh -X telorb@to14io1
      Password: tsP4ever
      cd /opt/telorb/system
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/name.epct .
      Password: tsP4ever
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/telorb.epct .
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/nm.epct .
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/SS7.epct .
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/refapp.epct .
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/vip.epct .

    Continue after "First time" further down.

--- Start: First time ---
    (For reference reasons, I fetched the following config files for to29 to
     my WS:
      cd /home/uabmsu/telorb/upgradepath_tsp4to5/to29_config_files
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/name.epct .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/nm.epct .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/name.epct .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/Node_data.dat .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/refapp.epct .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/SS7.epct .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/telorb.conf .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/telorb.epct .
      scp telorb@134.138.186.249:/home/qperulf/telorb/upgradepath/WP51/RM453/to29/vip.epct .)

- Manually, check if (the) epct files need to be adjusted, changed and/or added.

  Considerations for telorb.epct:
    o You may want to extract the NAME setting in the telorb.epct file to a
      separate name.epct file, to make the build of upgrade packages easier
      later on.
    o Verify that the correct processors have become Dicos and Linux,
      respectively.
    o TIME_DST_DATES = (2005032702,1, 2005103002,0)
    o Change e.g. "VipOspf_AreaID = "2887650830"" to valid value, e.g.:
        VipOspf_AreaID = "10.0.0.0"
      Do NOT add:
        VipOspf_HelloInterval = 10
        VipOspf_RouterDeadInterval = 40
    o Add:
        SocketUserDistributionCfg_16 = "0x800:6:10000:roundRobinDistributor"
    o Add an alias to the VIP address (add 40 to the last value of the VIP
      address), e.g.:
        From
          i4ddCommand_310 = "ifconfig i4dd0 inet 172.30.14.14"
        to
          i4ddCommand_310 = "ifconfig i4dd0 inet 172.30.14.14 alias 172.30.14.54"

    Note: DorbExternalIIOPHostName = "172.30.14.14" and i4dd1
          will be considered in the nm.epct file.

  Considerations for SS7.epct:
    o PCFslave_itu_Pool should NOT be assigned to any of the Linux processors.
      If so, comment the appropriate lines out, e.g.:
        From
          PROCESSOR Proc_m0_s11 ALSO IN 
                     PCFslave_itu_Pool;

          PROCESSOR Proc_m0_s13 ALSO IN 
                     PCFslave_itu_Pool;
        to
          //  PROCESSOR Proc_m0_s11 ALSO IN 
          //             PCFslave_itu_Pool;

          //  PROCESSOR Proc_m0_s13 ALSO IN 
          //             PCFslave_itu_Pool;
--- End: First time ---

Now, it is time to build the loadingGroup01_1 and loadingGroup01_2 on the IOs.

  - Make sure all valid epct files are located below directory
    /opt/telorb/system/ on IO1:
      ls -l /opt/telorb/system/

  - Copy and unpack the TSP4 RefApp software from tbAD14lp11 to IO1:
      (Fetched the RefApp IDPG from qperulf to my WS:
         cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/refapp_tbAD14lp11
         scp telorb@134.138.186.249:/home/qperulf/data/RM453/Refapp/initial/REFAPP_IDPG.tgz .)
       From IO1:
         cd /opt/telorb/system
         mkdir refapp_tbAD14lp11
         cd refapp_tbAD14lp11
         scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/refapp_tbAD14lp11/REFAPP_IDPG.tgz .
         tar zxf REFAPP_IDPG.tgz

  - Perform `epconfig set' on IO1:
      tcsh
      cd /opt/telorb/system
      epconfig s -r /opt/telorb/system/refapp_tbAD14lp11/REFAPP_IDPG

  - Build the loadingGroups:
      epct -X name.epct telorb.epct nm.epct SS7.epct refapp.epct vip.epct

  - Copy loadingGroup01_2, and SS7 parts (if applicable) from IO1 to IO2 and
    configure SS7:
      cd /home/telorb/TSP-4.0-RM453-2-0/config/scripts
      ./loadscript2.sh
        :
      Is "172.30.14.14" your external VIP address? (it is the same as the addr. in "i4ddCommand_310" in telorb.epct)
      (y/n)                                                 y
      *  4.2 Run the DCM configuration script
      Type root password.
      Password: rootroot
      /opt/DCM created succesfully.
      /opt/telorb/logd created succesfully.
      Script: DCM_TCAP_ITU.sh  done
      * 4.2.2 Ready 
      *  4.2.3  Edit cp_tcap_itu.cnf file in IO1
      * Copy external vip address to "cp_tcap_itu.cnf" 172.30.14.14
      * Copy internal vip address to "cp_tcap_itu.cnf" 172.16.0.129
      * 4.2.3 Ready 
      Are you running a micro system with one mag ? y/n     n
      This are the default settings for the FE's and BE's ?
      BE|7|1|
      BE|15|2|
      FE|7|1|
      FE|15|2|
      Are these settings correct? y/n    n
      Enter 1'st BE Processor_ID
      9                              (E.g. 1st SS7 card's position in epct file)
      Enter 2'nd BE Processor_ID
      10                             (E.g. 2nd SS7 card's position in epct file)
      Enter 1'st BE Instance_ID
      1                              (Sequence number)
      Enter 2'nd BE Instance_ID
      2                              (Sequence number)
      Enter 1'st FE Processor_ID
      9
      Enter 2'nd FE Processor_ID
      10
      Enter 1'st FE Instance_ID
      1
      Enter 2'nd FE Instance_ID
      2
      These are your new settings for the FE's and BE's ?
      BE|9|1|
      BE|10|2|
      FE|9|1|
      FE|10|2|
      Are they OK? y/n   y
      * 4.2.4 Ready 
      *  4.2.5 Creation of the NMM/BE/FE CNF files for TCAP ITU stacks using DCM
      Copy dcm file, file with "LS" is for load sharing
      1   2BE_2FE_2Linkset_16Links_ANSI_TCAP_ITU_NW.dcm
      2   2BE_2FE_2Linkset_16Links_ITU-ANSI_TCAP_ITU_NW.dcm
      3   2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW.dcm
      4   2BE_2FE_2Linkset_16Links_ITU_TCAP_LS_ITU_NW.dcm
      Enter a file no. or n to terminate the script
      3
      * 4.2.5 Ready 2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW.dcm copied to opt/DCM
      --------------------------------------------------------------------------
      End of loadscript2

  - Edit the file pcf_tcap_itu.cnf with HSL stuff:
      cd /opt/telorb/axe/loadingGroup01_1/mirrored/cnf
      emacs pcf_tcap_itu.cnf &
        Change the file from e.g.
          FE|9|1|/cnf/fe0.cnf
          FE|10|2|/cnf/fe1.cnf
        to e.g.
          FE|9|1|/cnf/fe1_hslatm.cnf
          FE|10|2|/cnf/fe2_hslatm.cnf

  - Open DCM browser:
      tcsh
      cd /opt/DCM/
      echo $PATH    (Should contain "/opt/java/bin")
      ./ss7dcm

  - Perform the following in the DCM browser:
      File -> Open...
        o Select the DCM template file, e.g.
            "2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW.dcm".
          and click "Open".
        o Go to SS7 system -> Physical Architecture -> Right click on OAM
          -> Properties.
        o Set "CP Manager Host" = <External VIP address>, e.g.
          172.30.14.xx.
        o Set "CP Manager Port" = 8600 (default value).
        o Set "Distribution Mode" = Local (default value).
        o Set "Local Config. Location" =
          /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/ (default value).
        o Click the X at the top right hand corner of the "OAM" panel, to close
          it.
        Distribute config files with DCM:
        o Go to SS7 system -> Right click on Physical Architecture ->
          Control Panel....
        o Tick all boxes, i.e. the boxes for:
          - NMM
          - All BEs
          - All FEs
        o Click "Distribute config".
        o Click "Close" to close the "DCM Control Panel" panel.
        Save DCM and close the DCM GUI:
        o File -> Save as....
        o Select the DCM template file and add e.g. the system name (to14):
            "2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW_to14.dcm"
          and click "Save".
          The file "2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW_to14.dcm" will be
          saved at /opt/DCM.
          You may want to store the file outside the IO for reuse the next time
          you come to this point:
            On e.g. WS:
              cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14
              scp telorb@to14io1:/opt/DCM/2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW_to14.dcm .
        Exit DCM:
        o File -> Exit

  - Verify that "cnf files" have been created:
      ls -l /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/*.cnf
-rw-rw-r--    1 telorb   telorb      13603 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/be.cnf
-rw-rw-r--    1 telorb   telorb        661 Oct 31 09:52 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/cp_tcap_itu.cnf
-rwxrwxr-x    1 telorb   telorb       7273 Oct 31 09:52 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/e1pmcsetup.cnf
-rw-rw-r--    1 telorb   telorb       1156 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/fe0.cnf
-rw-rw-r--    1 telorb   telorb       1441 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/fe0_l2_0.cnf
-rw-rw-r--    1 telorb   telorb       3318 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/fe0_mux_0.cnf
-rw-rw-r--    1 telorb   telorb       1156 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/fe1.cnf
-rw-rw-r--    1 telorb   telorb       1441 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/fe1_l2_0.cnf
-rw-rw-r--    1 telorb   telorb       3318 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/fe1_mux_0.cnf
-rw-rw-r--    1 telorb   telorb      12632 Oct 31 13:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/nmm.cnf
-rwxrwxr-x    1 telorb   telorb        409 Oct 31 09:52 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/oam.cnf
-rw-rw-r--    1 telorb   telorb        403 Oct 31 11:01 /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/pcf_tcap_itu.cnf

  - Congigure NM (copy NM files, insert VIP address and node name):
      cd /home/telorb/TSP-4.0-RM453-2-0/config/scripts
      ./loadscript3.sh
        :
       Is "172.30.14.14" your external VIP address? (it is the same as the addr. in "i4ddCommand_310" in telorb.epct)
(y/n)            y
      *  4.3.1 Copy Platform NetRed Pots to mirrored directory
      *  TSP4-002-NetShared-POT.config copied to: /home/telorb/TSP-4.0-RM453-2-0/config/NetSharedPOT
      * 4.3.1 Ready 
      *  4.3.2 Create required directories in both IO1 and IO2
      * 4.3.2 Ready 
      *  4.3.3 Run the configuration script
      Enter root password
      Password: rootroot
      Creating directories under .../mirrored/config
      Copying template configuration files to the correct directories
      Copying slapd.conf
      Copying snmpd.conf
      Copying ftu.conf
      Copying nm.conf
      Copying env.sh
      Copying alex.conf
      Copying sys_structure.conf
      Copying omnidaemon.conf
      Copying snmpport.dat
      Copying toolbox.conf
      Copying logging.conf
      Copying ca.config and sign.sh
      Copying targetaddr.dat
      Copying telorb.pmf.properties
      Change ownership and mode for everything beneath loadingGroup01_1
      Changing mode on specific files
      Install rpm for MySQL client
      Preparing...                ########################################### [100%]
         1:MySQL-client           ########################################### [100%]
      Script: NM_configuration.sh  done
      * 4.3.3 Ready 
      *  4.3.4 Run the node_name script
      Will you use the default name "jambala" as node name? y/n   y
      You are on the point to change the Node Name to jambala
      -------- Modifying File : /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_PMFCORE_R4N03-PMFCORE/config/PlatformMeasures.ldif
      -------- Modifying File : /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_PMFCORE_R4N03-PMFCORE/config/DiskMeasures.ldif
      -------- Modifying File : /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_PMFCORE_R4N03-PMFCORE/config/SigMeas.ldif
      -------- Modifying File : /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_NRMon_R7B04-NRMon/config/NRPmRedundancy.ldif
      -------- Modifying File : /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JIM_R9A02-JIM/config/OamProvisioningCounter.ldif
      -------- Modifying File : /opt/telorb/axe/loadingGroup01_1/mirrored/config/NM/ConfigurationManagement/nm.conf
      -------- Modifying File : /opt/telorb/axe/loadingGroup01_1/mirrored/config/NM/ftu/config/ftu.conf
      -------- Modifying File : /opt/telorb/axe/loadingGroup01_1/mirrored/config/NM/jim/ldap/config/slapd.conf
      -------- Modifying File : /opt/telorb/axe/loadingGroup01_1/mirrored/config/NM/jim/snmp/config/snmpd.conf
      The changes are done
      *  Node name is jambala 
      * 4.3.4 Ready 

      *  4.3.5 Set external vip address in logging.conf
      *  VIP address changed from 192.168.63.100 to 172.30.14.14
      * 4.3.5 Ready 

      *  4.3.6 Edit nm.conf
      *  Insert  external vip address 172.30.14.14 in "nm.conf"
      * 4.3.6 Ready 

      *  4.3.7 Edit Alexserv conf files
      * HttpdHost: set to 172.30.14.14
      * 4.3.7 Ready 

      *  4.3.8 Edit Edit omnidaemon.conf

      Change XXX to your host name in string: "Active Library Explorer Installation at XXX"
      enter your Host name       to14
      Is to14 correct  y/n?    y
      *  Host name set to to14
      * 4.3.8 Ready 

      *  4.3.9 Copy the Alarm SNMP Agent configuration file into mirrored directory
      * 4.3.9 Ready

      *  4.3.10 Edit targetaddr.dat
      * 4.3.10 Ready 

      *  4.3.11 Edit toolbox.conf
      * 4.3.11 Ready 

      *  4.10.13 Configure mirrored directories in IO2
      * 4.3.11 Ready 

      * If you have an SNMP client machine you have to edit the file "targetaddr.dat"
      * when this script is ready.
      * The path to "targetaddr.dat" is:
      * "opt/telorb/axe/loadingGroup01_1/mirrored/config/NM/FaultManagement/data"
      *
      *
      End of loadscript3

- Physically, reset all traffic processors and make sure the INITIAL Dicos
  loader starts loading before the second Dicos loader.
  Do not reset the IO processors.

- On IO1, verify that all processors have come up and are running (you may also
  verify the loading of each processor by monitoring the processor console
  logs, see below):
    tail -f /opt/telorb/consolelogs/Proc* | grep "Total functionality"
    Ctrl-c

- On IO1, start the processor console logs:
    Create a start_consoles file below /opt/telorb/consolelogs/ and start it:
      /opt/telorb/consolelogs/start_consoles
        (I have created start_consoles and stop_consoles files for to14, which
         may serve as a templates, and they can be fetched from:
          cd /opt/telorb/consolelogs
          scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/start_consoles .
          scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/stop_consoles .)

- On IO1, verify that the external VIP address is working:
    on IO1:
      ping 172.30.14.xx
      Ctrl-c

- On IO1, create, initiate and configure the Mysql database:
    cd /home/telorb/TSP-4.0-RM453-2-0/config/scripts
    ./loadscript4.sh
      Is "172.30.14.14" your external VIP address? (it is the same as the addr. in "i4ddCommand_310" in telorb.epct)
      (y/n)   y
      # 4.4.1 Check if "mysql" is running, and check that it's only running on one processor
      Please be patient, this will take about 90 seconds
      Connection closed by foreign host.
      Connection closed by foreign host.

      MySql is running on 172.16.0.13

      mysql is running on 172.16.0.13

      # 4.4.1 Ready

      # 4.4.2 Initiate logging DB

      **************************************************
      Expect: ERROR 1050 at line 1: Table...
      **************************************************
 
      # 4.4.2 Ready
 
      # 4.4.3 Create Logging Table for JIM
 
      ERROR 1051 at line 1: Unknown table 'JIM'
      ERROR 1051 at line 1: Unknown table 'JIM'
 
      **************************************************
      Expect: ERROR 1051 at line 1: Unknown table 'JIM'
      **************************************************

      # 4.4.4 Create Logging Table for Logging of alarms
 
      ERROR 1051 at line 1: Unknown table 'Alarm'
      ERROR 1051 at line 1: Unknown table 'Alarm'
 
      ***************************************************
      Expect: ERROR 1051 at line 1: Unknown table 'Alarm'
      ***************************************************
 
      # 4.4.5 Create Logging Table for Logging of notifications
      ERROR 1051 at line 1: Unknown table 'Notification'
      ERROR 1051 at line 1: Unknown table 'Notification'
 
      **********************************************************
      Expect: ERROR 1051 at line 1: Unknown table 'Notification'
      **********************************************************

      # 4.4.6 Verify that the tables are created in logging db
      # 4.4.6 Ready
      # 4.4.7 Reconfigure DicosApplog
 
      Copying configuration files to /opt/telorb/axe/loadingGroup01_1/mirrored/applogConfig
      Restarting DicosAppLog (pid 2422)...
      Done.
      4.4.7 Ready
 
      # 4.4.8 Configuration of public key's for FTU
      172.16.0.11 :
      telnet> Trying 172.16.0.11...
      Connected to nset interrupt
      .
      Escape character is '^]'.
      Last login: Mon Oct 31 16:18:57 from io1
      ########################################################################
      #      This system is for the use of authorized users only.	       #
      #      Individuals using this computer system without authority, or in #
      #      excess of their authority, are subject to having all of their   #
      #      activities on this system monitored and recorded by system      #
      #      personnel.                                                      #
      #                                                                      #
      #      In the course of monitoring individuals improperly using this   #
      #      system, or in the course of system maintenance, the activities  #
      #      of authorized users may also be monitored.                      #
      #                                                                      #
      #      Anyone using this system expressly consents to such monitoring  #
      #      and is advised that if such monitoring reveals possible         #
      #      evidence of criminal activity, system personnel may provide the #
      #      evidence of such monitoring to law enforcements officials.      #
      ########################################################################
      [telorb@hn0 telorb]$ cd /opt/3rdParty/NM/ftu/config; cp /opt/telorb/axe/loading
      Group01_1/mirrored/config/NM/ftu/config/id_dsa_ftu . 
      [telorb@hn0 config]$ Connection closed by foreign host.
      172.16.8.11 :
      telnet> Trying 172.16.8.11...
      Connected to nset interrupt
      .
      Escape character is '^]'.
      Last login: Mon Oct 31 16:20:34 from io1
      ########################################################################
      #      This system is for the use of authorized users only.	       #
      #      Individuals using this computer system without authority, or in #
      #      excess of their authority, are subject to having all of their   #
      #      activities on this system monitored and recorded by system      #
      #      personnel.                                                      #
      #                                                                      #
      #      In the course of monitoring individuals improperly using this   #
      #      system, or in the course of system maintenance, the activities  #
      #      of authorized users may also be monitored.                      #
      #                                                                      #
      #      Anyone using this system expressly consents to such monitoring  #
      #      and is advised that if such monitoring reveals possible         #
      #      evidence of criminal activity, system personnel may provide the #
      #      evidence of such monitoring to law enforcements officials.      #
      ########################################################################
      [telorb@hn0 telorb]$ cd /opt/3rdParty/NM/ftu/config; cp /opt/telorb/axe/loading
      Group01_1/mirrored/config/NM/ftu/config/id_dsa_ftu . 
      [telorb@hn0 config]$ Connection closed by foreign host.
      172.16.0.13 :
      telnet> Trying 172.16.0.13...
      Connected to nset interrupt
      .
      Escape character is '^]'.
      Last login: Mon Oct 31 16:19:42 from io1
      ########################################################################
      #      This system is for the use of authorized users only.	       #
      #      Individuals using this computer system without authority, or in #
      #      excess of their authority, are subject to having all of their   #
      #      activities on this system monitored and recorded by system      #
      #      personnel.                                                      #
      #                                                                      #
      #      In the course of monitoring individuals improperly using this   #
      #      system, or in the course of system maintenance, the activities  #
      #      of authorized users may also be monitored.                      #
      #                                                                      #
      #      Anyone using this system expressly consents to such monitoring  #
      #      and is advised that if such monitoring reveals possible         #
      #      evidence of criminal activity, system personnel may provide the #
      #      evidence of such monitoring to law enforcements officials.      #
      ########################################################################
      [telorb@hn0 telorb]$ cd /opt/3rdParty/NM/ftu/config; cp /opt/telorb/axe/loading
      Group01_1/mirrored/config/NM/ftu/config/id_dsa_ftu . 
      [telorb@hn0 config]$ Connection closed by foreign host.
      172.16.8.13 :
      telnet> Trying 172.16.8.13...
      Connected to nset interrupt
      .
      Escape character is '^]'.
      Last login: Mon Oct 31 16:20:38 from io1
      ########################################################################
      #      This system is for the use of authorized users only.	       #
      #      Individuals using this computer system without authority, or in #
      #      excess of their authority, are subject to having all of their   #
      #      activities on this system monitored and recorded by system      #
      #      personnel.                                                      #
      #                                                                      #
      #      In the course of monitoring individuals improperly using this   #
      #      system, or in the course of system maintenance, the activities  #
      #      of authorized users may also be monitored.                      #
      #                                                                      #
      #      Anyone using this system expressly consents to such monitoring  #
      #      and is advised that if such monitoring reveals possible         #
      #      evidence of criminal activity, system personnel may provide the #
      #      evidence of such monitoring to law enforcements officials.      #
      ########################################################################
      [telorb@hn0 telorb]$ cd /opt/3rdParty/NM/ftu/config; cp /opt/telorb/axe/loading
      Group01_1/mirrored/config/NM/ftu/config/id_dsa_ftu . 
      [telorb@hn0 config]$ Connection closed by foreign host.
      # 4.4.8 Ready
 
      # 4.4.9 initiate regular removal of old measurement data files
      no crontab for telorb

      # DO NOT EDIT THIS FILE - edit the master and reinstall.
      # (/opt/telorb/axe/loadingGroup01_1/mirrored/config/PMF/IoMeasures/config/cleanup.crontab installed on Mon Oct 31 16:20:42 2005)
      # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
      0 0 * * * /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_IOMEASURES_R4J03-IOMEASURES/scripts/cleanup_script /opt/telorb/axe/reporterLogs +30

      Crontab loaded

      # 4.4.9 Ready
 
      # 4.4.10 Scheduling of Logging Archiver

      This script creates and drops temporary database tables in the logging database.
      In order to avoid loosing data, please DO NOT USE tablenames which begin with 'tsp_old_' or 'tsp_temp_'!
      Creating tables with such names, might result in loosing data when the daily archive scrpit is run.

      Alarm
      Archiving table Alarm in logging database finished successfully.

      JIM
      Archiving table JIM in logging database finished successfully.

      Notification
      Archiving table Notification in logging database finished successfully.

      Starting process Archiver
      # 4.4.10 Ready

      # 4.4.11 Check logging table
      Tables_in_logging
      Alarm
      Application
      JIM
      LoggingSeparator
      Notification
      XMLDBMSKey
      criteria

      # 4.4.11 Tables_in_logging are ok
      --------------------------------------------------------------------------
 
       4.5.0 Generate a self-signed server certificate
       These are the default settings:
 
        Country Name (2 letter code)                  []: SE
        State or Province Name (full name)            []: Stockholms LAN
        Locality Name (eg, city)                      []: Stockholm
        Organization Name (eg, company)               []: LM Ericsson Telephone Company
        Organizational Unit Name (eg, section)        []: TSP
        Common Name (eg, YOUR name)                   []: Your VIP address
        Email Address                                 []: -
        A challenge password                          []: -
        An optional company name                      []: -
 
      Do you want to use default settings? y/n     y

      Default settings will be used

      4.5.1 SSL Configuration
      --------------------------------------------------------------------------

      Generate the Server Key:
      NOTE: The "<server key pass phrase>" is any pass phrase you want, for example, telorb.
 
       Enter root PW
      Password: rootroot
      warning, not much extra random data, consider using the -rand option
      Generating RSA private key, 1024 bit long modulus
      ......................++++++
      ...................++++++
      e is 65537 (0x10001)
      Enter PEM pass phrase:
      Verifying password - Enter PEM pass phrase:
       4.5.2  Decrypt the server key:
      --------------------------------------------------------------------------
      NOTE: The "<Enter PEM pass phrase:>" is any pass phrase you want, for example, telorb.
      read RSA key
      Enter PEM pass phrase:
      writing RSA key

       4.5.3  Build the CSR (Certificate Signing Request):

      Using configuration from /usr/share/ssl/openssl.cnf
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [AU]:State or Province Name (full name)
      [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company)
      [Internet Widgits Pty Ltd]:Organizational Unit Name (eg, section)
      []:Common Name (eg, your name or your server's hostname) []:Email Address []:
      Please enter the following 'extra' attributes
      to be sent with your certificate request
      A challenge password []:An optional company name []: 4.5.3  Default settings used
       4.5.4 Create a Certificate Authority (CA) Key:
 
      ** Enter PEM pass phrase: <server key pass phrase>
      warning, not much extra random data, consider using the -rand option
      Generating RSA private key, 1024 bit long modulus
      ...++++++
      .....................++++++
      e is 65537 (0x10001)
      Enter PEM pass phrase:
      Verifying password - Enter PEM pass phrase:
       4.5.5 Create a Self-Signed CA Certificate:

      Using configuration from /usr/share/ssl/openssl.cnf
      Enter PEM pass phrase:
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [AU]:State or Province Name (full name)
      [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company)
      [Internet Widgits Pty Ltd]:Organizational Unit Name (eg, section)
      []:Common Name (eg, your name or your server's hostname) []:Email Address []:
      4.5.6 Default values are used
      --------------------------------------------------------------------------
       4.5.7 Sign the Server Certificate with the CA Certificate:
      CA signing: server.csr -> server.crt:
      Using configuration from ca.config
      Enter PEM pass phrase:
      Check that the request matches the signature
      Signature ok
      The Subjects Distinguished Name is as follows
      countryName           :PRINTABLE:'SE'
      stateOrProvinceName   :PRINTABLE:'Stockholms LAN'
      localityName          :PRINTABLE:'Stockholm'
      organizationName      :PRINTABLE:'LM Ericsson Telephone Company'
      organizationalUnitName:PRINTABLE:'TSP'
      commonName            :PRINTABLE:'172.30.14.14'
      Certificate is to be certified until Oct 29 15:23:53 2015 GMT (3650 days)
      Sign the certificate? [y/n]:y

      1 out of 1 certificate requests certified, commit? [y/n]y
      Write out database with 1 new entries
      Data Base Updated
      CA verifying: server.crt <-> CA cert
      server.crt: OK
      Loadscript 4 part two
      --------------------------------------------------------------------
 
      4.6 Platform and Disk Measures Configuration
 
        4.6.1 Configuration of DiskMeasures for PMF
 
          4.6.1.1 Io1
 
      Enter root pw
      Password: rootroot
      Generating public/private dsa key pair.
      Created directory '/root/.ssh'.
      Your identification has been saved in /root/.ssh/id_dsa.
      Your public key has been saved in /root/.ssh/id_dsa.pub.
      The key fingerprint is:
      51:5f:1b:17:12:f1:7c:b6:2c:f9:8c:15:56:95:4b:91 root@io1.localdomain
 
      Expecte printout: 
 
      ** Generating public/private dsa key pair.
      ** Your identification has been saved in /root/.ssh/id_dsa.
      ** Your public key has been saved in /root/.ssh/id_dsa.pub.
      ** The key fingerprint is:
      **5f:8b:e9:65:08:d5:30:11:51:c7:58:c3:59:04:20:7a root@io1.localdomain
 
      Copy loadscript5b.sh to io2
 
      loadscript5b.sh      100%       |***********************************************************|  1192       00:00    
      Now enter <ssh io2> to access io2 and run loadscript5b.sh at /home/telorb


  - Execute loadscript5b.sh on IO2:
      On IO2: /home/telorb/loadscript5b.sh
      Enter root pw
      Password: rootroot
      Generating public/private dsa key pair.
      Created directory '/root/.ssh'.
      Your identification has been saved in /root/.ssh/id_dsa.
      Your public key has been saved in /root/.ssh/id_dsa.pub.
      The key fingerprint is:
      9a:0e:45:66:fc:40:13:7e:f1:27:5f:72:4c:5f:83:c6 root@io2.localdomain
      Expecte printout: 
      ** Generating public/private dsa key pair.
      ** Your identification has been saved in /root/.ssh/id_dsa.
      ** Your public key has been saved in /root/.ssh/id_dsa.pub.
      ** The key fingerprint is:
      **5f:8b:e9:65:08:d5:30:11:51:c7:58:c3:59:04:20:7a root@io2.localdomain
      Enter <exit> to switch back to io1
      Continue at "Configuration of  Platform Measures and IO Measures"

  - Create a backup and perform a zone reload, to get the LDAP browser in the
    Toolbox to work properly.
    
  - Install JXplorer on PC:
      Verify that the Java Runtime Environment (jre) on the PC has version
      1.4 or newer:
        java -version

  - Follow the following instructions in "TSP 4 - Runtime Installation
    Instructions, RM453", doc no 1/1531-ANA 901 03/2-3 (Rev G):
      o 4.11.2    Only first time.
                  (Enter command "$JAVA_HOME/jre/javaws/javaws")
                  (jnlp configuration: In e.g. Mozilla web browser:
                     Edit -> Preferences... ->
                     Helper Applications, -> New Type ->
                     MIME Type: application/x-jnlp
                     Description: jxplorer (manually inserted by uabmsu
                     Extension: jnlp
                     Open it with: /usr/lib/SunJava2-1.4/jre/javaws/javaws)
      o 4.11.3    (Use "unique_node_name" = jambala)
      o 4.11.4    (Use "unique_node_name" = jambala)
      o 4.11.5
      o 4.11.6

  TSP4, RM453 has now been installed.

  - Continue to install TSP4, RM453, MCP1.


Installation of TSP4, RM453, MCP1
=================================
- Follow the instructions in "Minor Correction Package 1 on RM/CM 453 in
  TSP 4", doc no 109 47-ANA 901 03/2-6 (Rev D), as follows:

  - From the TelORB Manager: Disable the backup scheduler.

  - From the TelORB Manager: Create a backup named "Backup_B4_CM453_MCP1".

  - Copy the MCP1 upgrade package to IO1:
    On IO1:
      cd /tmp
      scp telorb@134.138.186.235:/home/uabmsu/telorb/upgradepath_tsp4_to_tsp5/RM453/MCP1/113_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz .
      Password: tsP4ever
      gtar -zxvf 113_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz

  - Modify the epct file for NM, i.e. new epct template files  (rev G) are
    available at /tmp/TSP-4.0-CM453-2-1/config/epct/node_mgt/ on IO1.
     Main changes:
       - //SOFTWARE IDP/CONFIGURATIONMANAGEMENT;	// CMF   (Commented)
       - CMModelPool removed.

      (For to14, I generated a new NM epct file from the template file
       Node_Mgt_nsp5_midi_zone1.epct and named it nm_mcp1.epct.
       Placed it on IO1 at /opt/telorb/system/ and also copied it to my WS:
       From WS:
         cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14
         scp telorb@to14io1:/opt/telorb/system/nm_mcp1.epct .)

  - Go to the RM distribution:
      cd /home/telorb/TSP-4.0-RM453-2-0

  - Install the MCP1 IDPs to the TSP4 distribution directory:
      tcsh
      source /opt/telorb/config/setup.csh
      ./installUpgrade /tmp/TSP-4.0-CM453-2-1

  - Set the default version to MCP1 level:
      ./setDefaultVersion ANA/90103/2 R10B01

  - Copy the MCP1 upgrade packages to /opt/telorb/axe/upgradePackages/:
      cd /tmp/TSP-4.0-CM453-2-1/upgradePackages
      cp -R * /opt/telorb/axe/upgradePackages/.

  - Change write permission to enable removal of the upgrade packages from the
    TelORB Manager:
      cd /opt/telorb/axe/upgradePackages
      chmod -R 775 TSP_CM453_to_MCP1*

  - Copy upgrade files to IO2:
      cd /home/telorb/TSP-4.0-RM453-2-0/system
      scp -r unix io2:

  - Execute the upgrade script on IO1 (IO1 will be automatically rebooted):
      su -
      Password: rootroot
      cd /home/telorb/TSP-4.0-RM453-2-0/system/unix
      ./io-upgrade-R1DtoR1E.sh

        If the script stops with the printout:
          "Error: Installed non-standard packages were found."
        it may help to remove the superflous 2.4.19 files using the
        "rpm -e" command (our Kickstart server is not correctly installed,
        i.e. some files are superflous):
          cd /lib/modules
          ls -l
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1A41
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1B04
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1B05

            2.4.19-R1A41 and 2.4.19-R1B05 should be removed.
            2.4.19-R1B04 should be kept.

          rpm -q -a  | grep kernel
            kernel-2.4.19-R1B05
            kernel-2.4.19-R1A41
            kernel-headers-2.4.9-34
            kernel-2.4.19-R1B04

          rpm -e --nodeps kernel-2.4.19-R1A41   (Remove)
          rpm -e --nodeps kernel-2.4.19-R1B05   (Remove)

          rpm -q -a | grep kernel
            kernel-headers-2.4.9-34
            kernel-2.4.19-R1B04

          ls -l
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1B04

          Rerun the script:
            cd /home/telorb/TSP-4.0-RM453-2-0/system/unix
            ./io-upgrade-R1DtoR1E.sh

  - Log back in to IO1:
      ssh -X telorb@to14io1
      Password: tel123orb

  - On IO1, start the processor console logs:
      /opt/telorb/consolelogs/start_consoles
 
  - From the TelORB Manager: Create a backup named "io1-CM453MCP1".

  - Execute the upgrade script on IO2 (IO2 will be automatically rebooted):
    From IO1:
      ssh io2
      su -
      Password: rootroot
      cd /home/telorb/unix
      ./io-upgrade-R1DtoR1E.sh

        If the script stops with the printout:
          "Error: Installed non-standard packages were found."
        it may help to remove the superflous 2.4.19 files using the
        "rpm -e" command (our Kickstart server is not correctly installed,
        i.e. some files are superflous):
          cd /lib/modules
          ls -l
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1A41
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1B04
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1B05

            2.4.19-R1A41 and 2.4.19-R1B05 should be removed.
            2.4.19-R1B04 should be kept.

          rpm -q -a  | grep kernel
            kernel-2.4.19-R1B05
            kernel-2.4.19-R1A41
            kernel-headers-2.4.9-34
            kernel-2.4.19-R1B04

          rpm -e --nodeps kernel-2.4.19-R1A41   (Remove)
          rpm -e --nodeps kernel-2.4.19-R1B05   (Remove)

          rpm -q -a | grep kernel
            kernel-headers-2.4.9-34
            kernel-2.4.19-R1B04

          ls -l
            drwxr-xr-x    4 root     root         4096 Oct 21 12:32 2.4.19-R1B04

          Rerun the script:
            cd /home/telorb/unix
            ./io-upgrade-R1DtoR1E.sh

  - From the TelORB Manager: Create a backup named "io2-CM453MCP1".

  - Remove upgrade files on IO2:
      ssh io2
      su -
      Password: rootroot
      rm -rf /home/telorb/unix
      exit
      exit

  - Upgrade File Servers (FSs), if any.
      Follow the instructions in "Minor Correction Package 1 on RM/CM 453 in
      TSP 4", doc no 109 47-ANA 901 03/2-6.


  Upgrading of IO tools on IO2:

  - Copy the new IO tools package from IO1 to IO2:
      On IO1:
        cd /home/telorb/TSP-4.0-RM453-2-0/system/unix
        cp tools.CXP901305.R3B01.tar /opt/telorb/
        scp tools.CXP901305.R3B01.tar io2:/opt/telorb/

  - Log in to IO2 and unpack the IO tools package:
      ssh -X telorb@to14io2
      Password: tel123orb
      cd /opt/telorb
      tar -xvf tools.CXP901305.R3B01.tar

  - On IO2, stop telorb services:
      cd /opt/telorb/etc
      ./stop_services

  - On IO2, rename the code archive directory:
      cd /opt/telorb
      mv codearchive codearchive_B4_CM453_MCP1
      mv codearchive.CXP901305.R3B01 codearchive

  - On IO2, copy the exports file to temp directory:
      cd /opt/telorb/etc
      cp exports /tmp/.

  - On IO2, install and start telorb services:
      su
      Password: rootroot
      cd /opt/telorb/codearchive/iom_scripts
      ./prepareTelORB.sh -p -c -i2
      exit

  - On IO2, copy back the exports file:
      cd /tmp
      cp exports /opt/telorb/etc/.  (or mv)
      rm exports

  - On IO2, restart telorb services:
      cd /opt/telorb/etc
      ./stop_services
      ./start_services

  - On IO2, move the new IO tools package and set link to it:
      cd /opt/OS/tar
      mv /opt/telorb/tools.CXP901305.R3B01.tar .
      ln -fs tools.CXP901305.R3B01.tar tools.tar

  - On IO2, verify that all telorb services are running:
      cd /opt/telorb/etc
      ./status_services


  Upgrading of IO tools on IO1:

  - On IO1, unpack the IO tools package:
      cd /opt/telorb
      tar -xvf tools.CXP901305.R3B01.tar

  - On IO1, stop telorb services:
      cd /opt/telorb/etc
      ./stop_services

  - On IO1, rename the code archive directory:
      cd /opt/telorb
      mv codearchive codearchive_B4_CM453_MCP1
      mv codearchive.CXP901305.R3B01 codearchive

  - On IO1, copy the exports file to temp directory:
      cd /opt/telorb/etc
      cp exports /tmp/.

  - On IO1, install and start telorb services:
      su
      Password: rootroot
      cd /opt/telorb/codearchive/iom_scripts
      ./prepareTelORB.sh -p -c -i1
      exit

  - On IO1, copy back the exports file:
      cd /tmp
      cp exports /opt/telorb/etc/.  (or mv)
      rm exports

  - On IO1, restart telorb services:
      cd /opt/telorb/etc
      ./stop_services
      ./start_services

  - On IO1, move the new IO tools package and set link to it:
      cd /opt/OS/tar
      mv /opt/telorb/tools.CXP901305.R3B01.tar .
      ln -fs tools.CXP901305.R3B01.tar tools.tar

  - On IO1, verify that all telorb services are running:
      cd /opt/telorb/etc
      ./status_services


  DCM upgrade:

  - From IO1, upgrade DCM:
      su -
      Password: rootroot
      tcsh
      source /opt/telorb/config/setup.csh
      cd /tmp/TSP-4.0-CM453-2-1/config/scripts
      ./DCMChange.sh
      exit
      exit


  MCP1 step1 upgrade:

  - Apply the TSP_CM453_to_MCP1_step1 upgrade package (smooth upgrade
     method). (~5 min)

      !!! 30 DicosCapsuleTextDump error dumps occurred on various Dicos
          processors with:
          CapsuleName: PCFslave_tcap_itu
          Reason: User abortion (no call chain if the process was idle)


  MCP1 step2 upgrade:

  - To save time, modify the upgrade package for MCP1 step2, so that a
    reboot upgrade will be performed instead of a redundancy reboot upgrade:
      emacs /opt/telorb/axe/upgradePackages/TSP_CM453_to_MCP1_step2/upgradeConfigurationData/upgradeControlData.01 &
        Change the line
          "UA:TSP_CM453_to_MCP1_step2:DicosRedundancyReboot:DicosNoDbu"
        to
          "UA:TSP_CM453_to_MCP1_step2:DicosReboot:DicosNoDbu".

        Verify that the upgrade method has changed:
          TelORB Manager -> Upgrades -> Rescan
          Should be "- - TSP_CM453_to_MCP1_step2".

  - Apply the TSP_CM453_to_MCP1_step2 upgrade package (reboot upgrade method).

  - From the TelORB Manager: Create a backup named "CM453_MCP1_final".

  - From the TelORB Manager: Enable the backup scheduler.

  - Continue to install TSP4, RM453, MCP2.


Installation of TSP4, RM453, MCP2
=================================
- Follow the instructions in "Minor Correction Package 2 on RM/CM 453 in
  TSP 4", doc no 109 47-ANA 901 03/2-10 (Rev D), as follows:

  - From the TelORB Manager: Disable the backup scheduler.

  - From the TelORB Manager: Create a backup named "Backup_B4_CM453_MCP2".

  - Copy the MCP2 upgrade package to IO1:
    On IO1:
      cd /tmp
      scp telorb@134.138.186.235:/home/uabmsu/telorb/upgradepath_tsp4_to_tsp5/RM453/MCP2/117_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz .
      Password: tsP4ever
      gtar -zxvf 117_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz
      rm 117_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz

  - Modify the epct file for NM, i.e. new epct template files  (rev H) are
    available at /tmp/TSP-4.0-CM453-2-2/config/epct/node_mgt/ on IO1.
     Main changes:
       - Add:
        "SocketUserDistributionCfg_13 = "0x800:6:0:clusterRoundRobinDistributor"      // For Corba communication - do not expose" to the NM epct file.
       - Comment "//SocketUserDistributionCfg_13 = "0x800:6:0:clusterRoundRobinDistributor"" in the SS7 epct file.

      (For to14, I generated a new NM epct file from the template file
       Node_Mgt_nsp5_midi_zone1.epct and named it nm_mcp2.epct.
       Also changed the SS7 epct file to SS7_mcp2.epct.
       Placed them on IO1 at /opt/telorb/system/ and also copied them to my WS:
       From WS:
         cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14
         scp telorb@to14io1:/opt/telorb/system/nm_mcp2.epct .
         scp telorb@to14io1:/opt/telorb/system/SS7_mcp2.epct .)

  - Go to the TSP runtime distribution:
      cd /home/telorb/TSP-4.0-RM453-2-0

  - Install the MCP2 IDPs to the TSP4 distribution directory:
      tcsh
      source /opt/telorb/config/setup.csh
      ./installUpgrade /tmp/TSP-4.0-CM453-2-2

  - Set the default version to MCP2 level:
      ./setDefaultVersion ANA/90103/2 R10C01

  - Copy the MCP2 upgrade packages to /opt/telorb/axe/upgradePackages/:
      cd /tmp/TSP-4.0-CM453-2-2/upgradePackages
      cp -R * /opt/telorb/axe/upgradePackages/.

  - Change write permission to enable removal of the upgrade packages from the
    TelORB Manager:
      cd /opt/telorb/axe/upgradePackages
      chmod -R 775 TSP_CM453_MCP1_to_MCP2*

  MCP2 step1 upgrade:

  - Apply the TSP_CM453_MCP1_to_MCP2_step1 upgrade package (smooth upgrade
     method). (~5 min)

      !!! 56 DicosCapsuleTextDump error dumps occurred on various Dicos
          processors with:
          CapsuleName: PCFslave_tcap_itu
          Reason: User abortion (no call chain if the process was idle)


  MCP2 step2 upgrade:

  - To save time, modify the upgrade package for MCP2 step2, so that a
    reboot upgrade will be performed instead of a redundancy reboot upgrade:
      emacs /opt/telorb/axe/upgradePackages/TSP_CM453_MCP1_to_MCP2_step2/upgradeConfigurationData/upgradeControlData.01 &
        Change the line
          "UA:TSP_CM453_MCP1_to_MCP2_step2:DicosRedundancyReboot:DicosNoDbu"
        to
          "UA:TSP_CM453_MCP1_to_MCP2_step2:DicosReboot:DicosNoDbu".

        Verify that the upgrade method has changed:
          TelORB Manager -> Upgrades -> Rescan
          Should be "- - TSP_CM453_MCP1_to_MCP2_step2".

  - Apply the TSP_CM453_MCP1_to_MCP2_step2 upgrade package (reboot upgrade method).

  - From the TelORB Manager: Create a backup named "CM453_MCP2_final".

  - From the TelORB Manager: Enable the backup scheduler.

  - Continue to install TSP4, RM453, MCP3.


Installation of TSP4, RM453, MCP3
=================================
- Follow the instructions in "Minor Correction Package 3 on RM/CM 453 in
  TSP 4", doc no 109 47-ANA 901 03/2-13 (Rev B), as follows:

  - From the TelORB Manager: Disable the backup scheduler.

  - From the TelORB Manager: Create a backup named "Backup_B4_CM453_MCP3".

  - Copy the MCP3 upgrade package to IO1:
    On IO1:
      cd /tmp
      scp telorb@134.138.186.235:/home/uabmsu/telorb/upgradepath_tsp4_to_tsp5/RM453/MCP3/121_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz .
      Password: tsP4ever
      gtar -zxvf 121_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz
      rm 121_19089-LZN9010214_6_EN_A_GTAR_GZIPV1.gtar.gz

  - Go to the TSP runtime distribution:
      cd /home/telorb/TSP-4.0-RM453-2-0

  - Install the MCP3 IDPs to the TSP4 distribution directory:
      tcsh
      source /opt/telorb/config/setup.csh
      ./installUpgrade /tmp/TSP-4.0-CM453-2-3

  - Set the default version to MCP3 level:
      ./setDefaultVersion ANA/90103/2 R10D01

  - Copy the MCP3 upgrade packages to /opt/telorb/axe/upgradePackages/:
      cd /tmp/TSP-4.0-CM453-2-3/upgradePackages
      cp -R * /opt/telorb/axe/upgradePackages/.

  - Change write permission to enable removal of the upgrade packages from the
    TelORB Manager:
      cd /opt/telorb/axe/upgradePackages
      chmod -R 775 TSP_CM453_MCP2_to_MCP3*

  MCP3 step1 upgrade:

  - Apply the TSP_CM453_MCP2_to_MCP3_step1 upgrade package (smooth upgrade
     method). (~5 min)

      !!! 78 DicosCapsuleTextDump error dumps occurred on various Dicos
          processors with:
          CapsuleName: PCFslave_tcap_itu
          Reason: User abortion (no call chain if the process was idle)


  MCP3 step2 upgrade:

  - To save time, modify the upgrade package for MCP2 step2, so that a
    reboot upgrade will be performed instead of a redundancy reboot upgrade:
      emacs /opt/telorb/axe/upgradePackages/TSP_CM453_MCP2_to_MCP3_step2/upgradeConfigurationData/upgradeControlData.01 &
        Change the line
          "UA:TSP_CM453_MCP2_to_MCP3_step2:DicosRedundancyReboot:DicosNoDbu"
        to
          "UA:TSP_CM453_MCP2_to_MCP3_step2:DicosReboot:DicosNoDbu".

        Verify that the upgrade method has changed:
          TelORB Manager -> Upgrades -> Rescan
          Should be "- - TSP_CM453_MCP2_to_MCP3_step2".

  - Apply the TSP_CM453_MCP2_to_MCP3_step2 upgrade package (reboot upgrade method).

  - From the TelORB Manager: Create a backup named "CM453_MCP3_final".

  - From the TelORB Manager: Enable the backup scheduler.

*** Start: Michel's extra checks ***
- On IO1, verify that all processor and GESB/SCB interfaces are alive by pinging
  them:
    /opt/OS/ping_all

- On IO1, check if there are any error dumps and/or crashcollector files:
    ls -l /opt/telorb/dumps/
    ls -l /opt/telorb/crashcollector/
    If there are any, and they were created before you reset all traffic
    processors, you can remove them. Otherwise, investigate them.

- From the TelORB Manager:
  - Check for any alarms and take necessary actions if undesired alarms are
    found.
*** End: Michel's extra checks ***

  - If the TSP RefApp is not already in the system, execute
    TSP4to5_TSP4_upgrade_refapp and thereafter continue below.

  - Populate the database and start TSP RefApp traffic.
      See "SYSTEM CONFIGURATION" above for details
      (TSP4to5_TSP4_system_configuration).
  - Start VIP traffic.
       Either by using the external VIP traffic generator(s) or from e.g. your
       PC:
         - Source a valid testbed, e.g.:
             source /ipims_dicos/BS2/tbWP046/Setup.csh

         - Start VIP traffic:
             `epgetpath LM/VIP101`/bin/VIPtrafficgenerator.LM_VIP101.R2A02.i486-Redhat-6.0 172.30.14.XX 5987 5988 
  - Create a backup version.

  - Continue with Upgrade Path Step 0.5, after adding traffic.


Add TSP RefApp (upgrade) and start traffic
==========================================
Only execute this if the TSP RefApp does not already exist on the system!
If it does, continue with Upgrade Path Step 0.5.

- Build upgrade package for TSP RefApp on e.g. tos2:
    cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5
    mkdir upgradepackage_refapp
    cd upgradepackage_refapp
    mkdir epws
    cd ..
    mkdir config_files_tsp4_cwos_nm_ss7
    cd config_files_tsp4_cwos_nm_ss7
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/name.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/name.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/nm_mcp2.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/refapp.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/SS7_mcp2.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/telorb.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/vip.epct .

    emacs name.epct -> name_refapp.epct

    cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/upgradepackage_refapp
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/refapp_tbAD14lp11/REFAPP_IDPG.tgz .
    tar zxf REFAPP_IDPG.tgz

    Create a config file from the TelORB Manager.
    Fetch config file from the system:
      scp telorb@to14io1:/opt/telorb/axe/loadingGroup01_1/TSP_CM453_MCP2_to_MCP3_step2.config .

    source /home/dicosarc10/archive/RM453/TSP-4.0-RM453-2-0/setup.csh
    setenv EP_WORKSPACE `pwd`/epws
    epconfig delete -a
    epconfig set -r REFAPP_IDPG

    epgetpath IDP/MD14  Should show /home/dicosarc10/archive/RM453/
                            TSP-4.0-RM453-2-0/system/TelORB/IDP_MD14_R5D01-Dicos

    epct -v -F -X -u TSP_CM453_MCP2_to_MCP3_step2.config ../config_files_tsp4_cwos_nm_ss7/name_refapp.epct ../config_files_tsp4_cwos_nm_ss7/telorb.epct ../config_files_tsp4_cwos_nm_ss7/nm_mcp2.epct ../config_files_tsp4_cwos_nm_ss7/SS7_mcp2.epct ../config_files_tsp4_cwos_nm_ss7/vip.epct ../config_files_tsp4_cwos_nm_ss7/refapp.epct

    cd upgradePackages/
    Check contents of 01 and 02 files.

    Upload to IO1:
    tar zcf to14_refapp.tgz to14_refapp
    scp refapp.tgz telorb@to14io1:/opt/telorb/axe/upgradePackages

    Apply the upgrade package.

  - Continue where you came from.


Precondition for step 0.5 NM only - Perform an IO backup Recommended!
========================================================
Perform IO backup by following the instructions in 26/1553-APR 901 268/3 Uen
(Rev G), as follows.
- Create an IO backup to tape as described below (Instructions gleaned
  without permission from qperulf):

  On IO2:
    su root
    chown telorb /dev/st0 /dev/nst0
    exit
    -------
    Clean the tape station.
    -------
    Insert a writable tape.
    -------

  On IO1:
    su root
    cd /
    cp -a etc home/etc.backup-`date --iso`
    tar --rsh-command=/usr/bin/ssh -clMf telorb@io2:/dev/st0
--label="`hostname`-backup-`date --iso`" root home opt/OS/tar opt/telorb
etc/ssh opt/DCM
    Printout:
      "etc/sysconfig/static-routes is not present on IO1."
    ~16:59 IO1 backup started.
    ~17:23 IO1 backup finished.
    rm -rf home/etc.backup-`date --iso`
    exit

  Verify the tape:
  On IO2:
    tar -tvRMf /dev/st0 > /tmp/io1_backup.list

    ~14:05 IO1 backup list generation started.

    ~14:19 IO1 backup list generation finished.

    No errors are reported.

  Check the generated list:
    less /tmp/io1_backup.list

  On IO2:
    mt -f /dev/st0 rewoffl
    -------
    Remove the backup tape.
    -------
    Insert a writable tape
    -------

  On IO2:
    su root
    cd /
    cp -a etc home/etc.backup-`date --iso`
    tar -clMf /dev/st0 --label="`hostname`-backup-`date --iso`" root home
opt/OS/tar opt/telorb etc/ssh
    ~17:27 IO2 backup started.
    ~??:?? IO2 backup finished.
    rm -rf home/etc.backup-`date --iso`

  Verify the tape:
  On IO2:
    tar -tvRMf /dev/st0 > /tmp/io2_backup.list

    ~14:40 IO2 backup list generation started.
    ~14:44 IO2 backup list generation finished.

    No errors are reported.

  Check the generated list:
    less /tmp/io2_backup.list


  On IO2:
    mt -f /dev/st0 rewoffl
    exit

  Get the kickstart version:
  On IO1:
    rpm -q kickstart-tsp
      Printout:
      kickstart-tsp-R1E01-1

  On IO2:
    rpm -q kickstart-tsp
      Printout:
      kickstart-tsp-R1E01-1

    -------
    Remove the backup tape.
    -------


Step 0.5 NM only - Smooth upgrade
=================================

(Use the following address to get deliveries from SI&V:
ftp://rftp.uab.ericsson.se/pub/SysInt/TSP5_2/delivery/UpgradePath/)

Since no generic upgrade packages for the upgrade path steps are currently
available, on e.g. CD/DVD, you have to build the upgrade package for this
step yourself.
These instructions, describe how to build upgrade packages on tos2.
To be able to access IO1 from tos2, a special mounting is required, which
is described below.

- Fix mountings from tos2 to IO1:
    On to14io1:
      cd /opt/telorb/etc
      more exports
        /opt/telorb 172.16.0.0/255.255.248.0(rw,sync) 172.16.8.0/255.255.248.0(rw,sync) 
        /opt 172.16.0.0/255.255.248.0(ro) 172.16.8.0/255.255.248.0(ro)
      cp exports exports.orig
      Add the following line at the end of the exports file:
        /home/telorb 134.138.184.0/255.255.248.0(rw)
      ./stop_services
      ./start_services

    On tos2:
      su
      Password: Axg561
      cd /etc
      Add the following line to the fstab file:
        to14io1:/home/telorb            /to14/to14io1/home              nfs     soft,bg,intr,rw
      cd /to14/to14io1
      mkdir home
      mount /to14/to14io1/home
      exit

    On to14io1:
      cd /home
      chmod 755 telorb

    On tos2:
      ls -l /to14/to14io1/home    (Verify connection)


Now it is time to start with the actual step 0.5 upgrade.

- Follow the instructions in the document "TSP5 Upgrade Instruction From TSP4",
  doc no 3/1531-ANA 901 04/1-1 (Rev PA5.9), as follows:

  - Check NM pool allocations, according to the document.

  - Create a copy of the telorb.epct and nm.epct files:
      cd /opt/telorb/system/
      cp telorb.epct telorb.epct.bac
      cp nm_mcp2.epct nm_mcp2.epct.bac

  - Use the TelORB Manager (Inventory) to check if JavaJim IDPs are loaded in
    the system, i.e. look for any IDP containing the phrase "JavaJim...".
    If JavaJim IDPs are NOT loaded, follow the instructions below. Otherwise,
    skip to upgrade path step 1.

  - On IO1:
      cd /tmp
      mkdir /tmp/NM_upgrade_step05

- If not already done,
  on e.g. WS, download the NM_Upgrade_step05.tgz file from
    ftp://rftp.uab.ericsson.se/pub/SysInt/TSP5_2/delivery/UpgradePath/Delivery1/Subsystem_content/NM:
      cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff
      Download.
      Make the files readable by all.
      Compare file sizes with
        /home/qperulf/data/UpgradePath_SIV/ on ulinpc249 (qperulf)

  - On IO1, copy the NM_Upgrade_step05.tgz file from WS to IO1:
      cd /tmp/NM_upgrade_step05
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff/NM_Upgrade_step05.tgz .
      Password: tsP4ever

      tar zxvf NM_Upgrade_step05.tgz

  - On IO1, create a dummy loadingGroup to get a .config file, that just
    contains the platform data:
      tcsh
      cd /opt/telorb/system
      cp name.epct name_orig.epct
      echo "NAME orig;" > name.epct
      epconfig d -a
      epct -F -d /tmp telorb.epct SS7_mcp2.epct nm_mcp2.epct name.epct
      
  - Set environment data for JavaJim:
      cd /tmp/NM_upgrade_step05/scripts
      ./setJavaJimEnvironmentData /tmp/orig.config

--------------------------------------------
--- INPUT FILE SPECIFIC SETTINGS
--------------------------------------------
loadingGroup "*.config" file: /tmp/orig.config
Node "telorb.conf" file:      /opt/telorb/etc/telorb.conf
Undo activated:               0
Mounting activated:           0
  
--------------------------------------------
--- IO1 ADDRESS
--------------------------------------------
IO1_1:                        172.16.0.129
IO1_2:                        172.16.8.129
--------------------------------------------
--- IO2 ADDRESS
--------------------------------------------
IO2_1:                        172.16.1.1
IO2_2:                        172.16.9.1

Shall I continue with the above settings (NO/yes)?        yes

Continuing with the "setJavaJimEnvironmentData" script execution...
Setting environment variable on Dicos TP: Proc_m0_s9 <172.16.0.9:8002>
Executing: setenv Jim.Installer.AppName1 JimJavaRoot
Executing: setenv Jim.Installer.InstallerName.JimJavaRoot1 se.ericsson.jambala.jim.management.configurationData.JimConfigInstaller
Executing: setenv Jim.Installer.Reinstall.JimJavaRoot True
Executing: setenv Jim.Application.EnableMoInstallTimer true
Executing: setenv Jim.ServerTimeLimit 1800
Executing: setenv Jim.ServerSizeLimit 200000
[ DONE ]

  - Create a backup version, named "NM_upgrade_step05_javajim_vars".

  - Since original epct file names are assumed, you need to re-arrange the
    epct file names on IO1, i.e. if you want to keep the original epct files
    which are valid for RM453:
      cd /opt/telorb/system/
      ls -l
total 320
-rwxrwxr-x    1 telorb   telorb         11 Nov 11 10:10 name.epct
-rwxrwxr-x    1 telorb   telorb        165 Nov 11 10:10 name_orig.epct
-rwxrwxr-x    1 telorb   telorb      20713 Oct 28 15:17 nm.epct
-rwxrwxr-x    1 telorb   telorb      20713 Oct 27 19:01 nm.epct.gen
-rw-rw-r--    1 telorb   telorb      20375 Nov  3 13:48 nm_mcp1.epct
-rw-rw-r--    1 telorb   telorb      20495 Nov  3 15:25 nm_mcp2.epct
-rw-rw-r--    1 telorb   telorb      20495 Nov  9 16:07 nm_mcp2.epct.bac
-rwxrwxr-x    1 telorb   telorb      20498 Nov  3 15:18 Node_Mgt_nsp5_midi_zone1.epct
-rwxrwxr-x    1 telorb   telorb       4631 Oct 28 15:38 refapp.epct
drwxrwxr-x    3 telorb   telorb       4096 Oct 28 17:07 refapp_tbAD14lp11
-rwxrwxr-x    1 telorb   telorb       9165 Oct 28 14:12 SS7.epct
-rwxrwxr-x    1 telorb   telorb       9157 Oct 27 19:01 SS7.epct.gen
-rw-rw-r--    1 telorb   telorb       9167 Nov  3 15:40 SS7_mcp2.epct
-rwxrwxr-x    1 telorb   telorb      38220 Oct 28 13:24 telorb.epct
-rwxrwxr-x    1 telorb   telorb      38220 Nov  9 16:06 telorb.epct.bac
-rwxrwxr-x    1 telorb   telorb      38089 Oct 27 19:01 telorb.epct.gen
-rwxrwxr-x    1 telorb   telorb        385 Oct 28 15:39 vip.epct

      less name.epct 
      mv nm.epct nm_orig.epct
      cp nm_mcp2.epct nm.epct
      mv SS7.epct SS7_orig.epct
      cp SS7_mcp2.epct SS7.epct

      ls -l
total 356
-rwxrwxr-x    1 telorb   telorb         11 Nov 11 10:10 name.epct
-rwxrwxr-x    1 telorb   telorb        165 Nov 11 10:10 name_orig.epct
-rw-rw-r--    1 telorb   telorb      20495 Nov 11 10:57 nm.epct
-rwxrwxr-x    1 telorb   telorb      20713 Oct 27 19:01 nm.epct.gen
-rw-rw-r--    1 telorb   telorb      20375 Nov  3 13:48 nm_mcp1.epct
-rw-rw-r--    1 telorb   telorb      20495 Nov  3 15:25 nm_mcp2.epct
-rw-rw-r--    1 telorb   telorb      20495 Nov  9 16:07 nm_mcp2.epct.bac
-rwxrwxr-x    1 telorb   telorb      20713 Oct 28 15:17 nm_orig.epct
-rwxrwxr-x    1 telorb   telorb      20498 Nov  3 15:18 Node_Mgt_nsp5_midi_zone1.epct
-rwxrwxr-x    1 telorb   telorb       4631 Oct 28 15:38 refapp.epct
drwxrwxr-x    3 telorb   telorb       4096 Oct 28 17:07 refapp_tbAD14lp11
-rw-rw-r--    1 telorb   telorb       9167 Nov 11 10:58 SS7.epct
-rwxrwxr-x    1 telorb   telorb       9157 Oct 27 19:01 SS7.epct.gen
-rw-rw-r--    1 telorb   telorb       9167 Nov  3 15:40 SS7_mcp2.epct
-rwxrwxr-x    1 telorb   telorb       9165 Oct 28 14:12 SS7_orig.epct
-rwxrwxr-x    1 telorb   telorb      38220 Oct 28 13:24 telorb.epct
-rwxrwxr-x    1 telorb   telorb      38220 Nov  9 16:06 telorb.epct.bac
-rwxrwxr-x    1 telorb   telorb      38089 Oct 27 19:01 telorb.epct.gen
-rwxrwxr-x    1 telorb   telorb        385 Oct 28 15:39 vip.epct

  - epconfig set the JavaJim IDPs:
      cd /tmp/NM_upgrade_step05/scripts/
      epconfig set -r /tmp/NM_upgrade_step05/IDPs/system/Telorb/

  - Modify the nm.epct file for smooth upgrade:
      ./setEpctStep05

  - Set new system name:
      cd /opt/telorb/system
      echo "NAME TSP4_to_TSP5_step05;" > name.epct

  - Build a smooth upgrade package:
      epct -u /tmp/orig.config telorb.epct nm.epct SS7.epct name.epct

os is i486-Redhat-6.0
epct: processing input file telorb.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_MD14_R5D01-Dicos/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_MD16_R1L01-Ethernet/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D13_R1M01-IntelPcProcessorManagement/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D16_R1AL01-FileSystemComponents/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D22_R1AG01-GemScbSupervision/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D36_R1T01-UDCRemoteServer/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_DUO2_R1K01-Net/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_MD11_R1F02-CommLinkUdpAdaptation/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_MD18_R3A01-Java/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D2_R2C01-NetRed/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D30_R1L01-LinuxIntelPcProcessorManagement/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_SU1_R5C01-TelorbLinux/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D38_R1V03-TelorbLinuxJava/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D32_R3A01-NetInet/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D35_R1AN01-NetInet/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D48_R1V01-TelorbLinuxNetInet/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_D49_R1B02-TelorbLinuxNetInetProcess/config.epct
epct: processing input file nm.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JIM_R9D01-JIM/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_PMFCORE_R5B01-PMFCORE/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_COMMONSERVICES_R6A01-CommonServices/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_LINUXCOMMONSERVICES_R6A01-LinuxCommonServices/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_cryptoServer_R5A01-cryptoServer/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_PMFUNIX_R5A01-PMFUnix/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JIMANONINSTALLER_R2A01-JIMANONINSTALLER/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JIMLDAP_R6B01-JimLdap/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JIMSNMP_R5A01-JimSnmp/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_XERCES_R5A01-Xerces/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_XALAN_R5A01-Xalan/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_OROMATCHER_R5A01-OROMatcher/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JDBC_R5A01-jdbc/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_XMLDB_R5A01-xmlDB/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_APACHE_R5A01-apache/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_TOMCAT_R5A01-tomcat/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_OPENSSH_R5A01-OpenSSH/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_OMTOOLBOX_R6A01-Toolbox/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_FTU_R5A01-FTU/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JXPLORER_R2B01-jxplorer/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_MYSQL_R5A01-mysql/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_LOGSQL_R5B01-LogSQL/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_QUERYTOOL_R6A01-QueryTool/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_JAPLOGGING_R4A01-JAPLOGGING/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_PMPLATFORMMEASURES_R5A01-PMPlatformMeasures/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_LINUXMEASURES_R5B01-LINUXMEASURES/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_IOMEASURES_R5B01-IOMEASURES/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_LAD_R6A01-LiveAlarmDisplay/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_SNMPAGENT_R5A01-snmpirp/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_IRPREPORTER_R5A01-IrpReporter/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_ALEXSERV_R5A01-Alexserv/config.epct
epct: processing IDP configuration file /tmp/NM_upgrade_step05/IDPs/system/Telorb/IDP_JavaJimServer/config.epct
epct: processing IDP configuration file /tmp/NM_upgrade_step05/IDPs/system/Telorb/IDP_JavaJimInstaller/config.epct
epct: processing input file SS7.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_EINSS7ITU_R7D01-IDPEINSS7ITU/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_E1T1DRIVER01_R1L01-EINSS7DRIVER_IDP/config.epct
epct: processing IDP configuration file /home/telorb/TSP-4.0-RM453-2-0/system/TelORB/IDP_PMSIGMEAS_R5D02-PMSIGMEAS/config.epct
epct: processing input file name.epct
epct: reading /tmp/orig.config
epct: building structure /opt/telorb/axe/upgradePackages/TSP4_to_TSP5_step05
epct: copying load files to /opt/telorb/axe/upgradePackages/TSP4_to_TSP5_step05/codeArchive
epct: Copying jar files to /opt/telorb/axe/upgradePackages/TSP4_to_TSP5_step05/copy-data/java
epct: generating /opt/telorb/axe/upgradePackages/TSP4_to_TSP5_step05/upgradeConfigurationData/upgradeControlData.01
epct: generating /opt/telorb/axe/upgradePackages/TSP4_to_TSP5_step05/upgradeConfigurationData/upgradeControlData.02
************************************************************
 The generated upgrade package TSP4_to_TSP5_step05 consists of :
      created IDP(s): IDP/CXP901478 IDP/CXP901720 
      created LM(s): LM/CXC1323950 LM/CXC1323951 LM/CXC1323952 LM/CXC1323949 
      created POT(s): JimPersistentObjectIndex.SWI_JIM_PUBLIC_PERSISTENT_MODEL JimAppMetaData.SWI_JIM_PUBLIC_PERSISTENT_MODEL 
      created PT(s): JIM_JavaServerProcess.SWI_JIM_INTERNAL_MANAGEMENT_PROCESS JimInstallerProcess.SWI_JIM_INTERNAL_MANAGEMENT_INSTALLERPROCESS 
      created DUT(s): JIM_JavaServerProcess_DUT.SWI_JIM_INTERNAL_MANAGEMENT_PROCESS JimPersistentObjectIndexDUT.SWI_JIM_INTERNAL_DISTRIBUTION JimMetaDataDut.SWI_JIM_INTERNAL_DISTRIBUTION JimInstallerProcessDUT.SWI_JIM_INTERNAL_MANAGEMENT_INSTALLERPROCESS 
      created POOL(s): JimJavaServerPool JimJavaInstallerPool 
      POOL(s) added to Processor(s): Proc_m1_s11 Proc_m3_s11 Proc_m1_s13 Proc_m2_s13 Proc_m0_s15 Proc_m3_s13 Proc_m1_s15 Proc_m2_s15 Proc_m0_s17 Proc_m3_s15 Proc_m1_s17 Proc_m2_s17 Proc_m0_s19 Proc_m3_s17 Proc_m1_s19 Proc_m2_s19 Proc_m3_s19 Proc_m3_s1 Proc_m1_s5 Proc_m3_s5 Proc_m3_s7 Proc_m3_s9 Proc_m2_s21 Proc_m3_s21 Proc_m0_s1 Proc_m0_s5 
**********************************************************
epct: generating /opt/telorb/axe/TSP4_to_TSP5_step05.config

Verify the contents of the upgrade package:
  more /opt/telorb/axe/upgradePackages/TSP4_to_TSP5_step05/upgradeConfigurationData/upgradeControlData.01
// Upgrade control data file 01 generated
// Fri Nov 11 11:23:34 2005 for telorb
UA:TSP4_to_TSP5_step05:DicosSmooth:DicosNoDbu

  more /opt/telorb/axe/upgradePackages/TSP4_to_TSP5_step05/upgradeConfigurationData/upgradeControlData.02
// Upgrade control data file 02 generated
// Fri Nov 11 11:23:34 2005 for telorb

POOL:JimJavaServerPool
POOL:JimJavaInstallerPool
IDP:IDP_JavaJimServer.IDP_CXP901478:IDP/CXP901478:R3A.20:Total
IDP:IDP_JavaJimInstaller.IDP_CXP901720:IDP/CXP901720:R3A.19:Total
LM:LM_JJIM_Java.LM_CXC1323950:LM/CXC1323950:R3A.16:IDP_JavaJimServer.IDP_CXP901478:IDP/CXP901478:Total:i486,418132,1056866862,183553628:LM/CXC1323949:LM/AXG490:LM/JIMDUTS:LM/CXC1323951:LM/CXC1323952:LM/JIMPOTS:LM/PMC:LM/FTU
LM:LM_JJIM_POT_C++.LM_CXC1323951:LM/CXC1323951:R3A.14:IDP_JavaJimServer.IDP_CXP901478:IDP/CXP901478:Total:i486,130836,-741709722,-841945627:LM/CXC1323952:LM/AXG490
LM:LM_JJIM_DUT_C++.LM_CXC1323952:LM/CXC1323952:R3A.14:IDP_JavaJimServer.IDP_CXP901478:IDP/CXP901478:Total:i486,3284,1469372544,1409445882
LM:LM_JJIM_Installer_Java.LM_CXC1323949:LM/CXC1323949:R3A.16:IDP_JavaJimInstaller.IDP_CXP901720:IDP/CXP901720:Total:i486,412328,324833309,253819200:LM/AXG490:LM/CXC1323951:LM/CXC1323952:LM/CXC1323950:LM/JIMPOTS:LM/PMC:LM/FTU:LM/JIMDUTS
DUT:606533,1,1:JIM_JavaServerProcess_DUT.SWI_JIM_INTERNAL_MANAGEMENT_PROCESS:SWI/JIM/INTERNAL/MANAGEMENT/PROCESS:R2B01:LM/CXC1323950:0,0,0:IDP/CXP901478:IDP_JavaJimServer:JimJavaServerPool:0
DUT:1009114,1,1:JimPersistentObjectIndexDUT.SWI_JIM_INTERNAL_DISTRIBUTION:SWI/JIM/INTERNAL/DISTRIBUTION:R2B01:LM/CXC1323952:1009114,1,1:IDP/CXP901478:IDP_JavaJimServer:JimJavaServerPool:0
DUT:1009128,1,1:JimMetaDataDut.SWI_JIM_INTERNAL_DISTRIBUTION:SWI/JIM/INTERNAL/DISTRIBUTION:R2B01:LM/CXC1323952:1009128,1,1:IDP/CXP901478:IDP_JavaJimServer:JimJavaServerPool:0
DUT:1009133,1,1:JimInstallerProcessDUT.SWI_JIM_INTERNAL_MANAGEMENT_INSTALLERPROCESS:SWI/JIM/INTERNAL/MANAGEMENT/INSTALLERPROCESS:R2B01:LM/CXC1323949:0,0,0:IDP/CXP901720:IDP_JavaJimInstaller:JimJavaInstallerPool:0
POT:1009087,1,1:JimPersistentObjectIndex.SWI_JIM_PUBLIC_PERSISTENT_MODEL:SWI/JIM/PUBLIC/PERSISTENT/MODEL:R2B05:1009114,1,1:SWI/JIM/INTERNAL/DISTRIBUTION:JimPersistentObjectIndexDUT.SWI_JIM_INTERNAL_DISTRIBUTION:IDP/CXP901478:IDP_JavaJimServer:1
POT:1009129,1,1:JimAppMetaData.SWI_JIM_PUBLIC_PERSISTENT_MODEL:SWI/JIM/PUBLIC/PERSISTENT/MODEL:R2B05:1009128,1,1:SWI/JIM/INTERNAL/DISTRIBUTION:JimMetaDataDut.SWI_JIM_INTERNAL_DISTRIBUTION:IDP/CXP901478:IDP_JavaJimServer:1
PT:612363,1,1:JIM_JavaServerProcess.SWI_JIM_INTERNAL_MANAGEMENT_PROCESS:SWI/JIM/INTERNAL/MANAGEMENT/PROCESS:R2B01:606533,1,1:SWI/JIM/INTERNAL/MANAGEMENT/PROCESS:JIM_JavaServerProcess_DUT.SWI_JIM_INTERNAL_MANAGEMENT_PROCESS:IDP/CXP901478:IDP_JavaJimServer:LM/CXC1323950:DynamicReplicated:1:1001450
PT:1009131,1,1:JimInstallerProcess.SWI_JIM_INTERNAL_MANAGEMENT_INSTALLERPROCESS:SWI/JIM/INTERNAL/MANAGEMENT/INSTALLERPROCESS:R2B01:1009133,1,1:SWI/JIM/INTERNAL/MANAGEMENT/INSTALLERPROCESS:JimInstallerProcessDUT.SWI_JIM_INTERNAL_MANAGEMENT_INSTALLERPROCESS:IDP/CXP901720:IDP_JavaJimInstaller:LM/CXC1323949:Central:1:1001450
SWPS:Proc_m1_s11:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s11:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m1_s13:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m2_s13:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m0_s15:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s13:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m1_s15:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m2_s15:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m0_s17:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s15:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m1_s17:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m2_s17:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m0_s19:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s17:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m1_s19:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m2_s19:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s19:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s1:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m1_s5:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s5:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s7:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s9:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m2_s21:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m3_s21:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m0_s1:1:JimJavaInstallerPool:JimJavaServerPool
SWPS:Proc_m0_s5:1:JimJavaInstallerPool:JimJavaServerPool

  - Apply the upgrade package TSP4_to_TSP5_step05.


Build upgrade package for step 0.5
----------------------------------

Note: This section is replaced by the section above!!!

Step 0.5: Only NM will be affected by this step.

- Make it possible to epconfig set TSP Ref App from tos2 to to14io1:
    On to14io1:
      cd /home/telorb
      cp -r /opt/telorb/system/refapp_tbAD14lp11/REFAPP_IDPG .

- Open a new shell to build the upgrade package from and enter the
  following:
    ssh -X telorb@tos2
    Password: tsP4ever

    cd /home/dicostest/tosFiles/to14/upgradepath/step05
    rm -rf *

- Create a .config file from the TelORB Manager.

- From tos2, fetch the .config file from the system:
    scp telorb@to14io1:/opt/telorb/axe/loadingGroup01_1/TSP_CM453_MCP2_to_MCP3_step2.config .

- Go to the directory where all valid epct files reside:
  cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/config_files_tsp4_cwos_nm_ss7

  mkdir epws

  source /to14/to14io1/home/TSP-4.0-RM453-2-0/setup.csh (Runtime environment)

  setenv EP_WORKSPACE `pwd`/epws

  epconfig delete -a

  epconfig set -r /to14/to14io1/home/REFAPP_IDPG        (TSP RefApp)

  epconfig set -r /ipims_dicos/BS2/tbAD14lp11.5NMSS7    (JavaJim...)

- Check if there are any TLMs to be used:
    ls -l /home/dicoshack/Hack/WP051/step05/

      If there are TLMs, then:
        epconfig set -r /home/dicoshack/Hack/WP051/step05/

- Add other TLMs, if any:
    epconfig set -r ...

  epct -d /home/dicostest/tosFiles/to14/upgradepath/step05 -XvFc -u /home/dicostest/tosFiles/to14/upgradepath/step05/TSP_CM453_MCP2_to_MCP3_step2.config name_step05.epct telorb.epct nm_mcp2.epct SS7_mcp2.epct vip.epct refapp.epct


Build upgrade package for TSP RefApp (Move this section to an appropriate
------------------------------------  location in this document)
- Build upgrade package for TSP RefApp on e.g. tos2:
    cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5
    mkdir upgradepackage_refapp
    cd upgradepackage_refapp
    mkdir epws
    cd ..
    mkdir config_files_tsp4_cwos_nm_ss7
    cd config_files_tsp4_cwos_nm_ss7
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/name.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/name.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/nm_mcp2.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/refapp.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/SS7_mcp2.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/telorb.epct .
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/initialstart_cwos_nm_ss7_to14/vip.epct .

    emacs name.epct -> name_refapp.epct

    cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/upgradepackage_refapp
    scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/refapp_tbAD14lp11/REFAPP_IDPG.tgz .
    Password: tsP4ever

    tar zxf REFAPP_IDPG.tgz

    Create a config file from the TelORB Manager.
    Fetch config file from the system:
      scp telorb@to14io1:/opt/telorb/axe/loadingGroup01_1/TSP_CM453_MCP2_to_MCP3_step2.config .

    source /home/dicosarc10/archive/RM453/TSP-4.0-RM453-2-0/setup.csh
    setenv EP_WORKSPACE `pwd`/epws
    epconfig delete -a
    epconfig set -r REFAPP_IDPG

    epgetpath IDP/MD14  Should show /home/dicosarc10/archive/RM453/
                            TSP-4.0-RM453-2-0/system/TelORB/IDP_MD14_R5D01-Dicos

    epct -v -F -X -u TSP_CM453_MCP2_to_MCP3_step2.config ../config_files_tsp4_cwos_nm_ss7/name_refapp.epct ../config_files_tsp4_cwos_nm_ss7/telorb.epct ../config_files_tsp4_cwos_nm_ss7/nm_mcp2.epct ../config_files_tsp4_cwos_nm_ss7/SS7_mcp2.epct ../config_files_tsp4_cwos_nm_ss7/vip.epct ../config_files_tsp4_cwos_nm_ss7/refapp.epct

    cd upgradePackages/
    Check contents of 01 and 02 files.

    Upload to IO1:
    tar zcf to14_refapp.tgz to14_refapp
    scp refapp.tgz telorb@to14io1:/opt/telorb/axe/upgradePackages

    Apply the upgrade package.

  - Continue where you came from.

Steps 1 and 2 CW/OS only - Smooth upgrade, IO tools update and Redundancy
Upgrade
=========================================================================

Preparation if not already done
-------------------------------
- To be able to use the same epct file for upgrade package creations,
  make sure that
    SOFTWARE IDP/SU1;	// TelorbLinux_IDP, Linux (Optional)
  is stated before
    SOFTWARE IDP/D2;	// NetRed_IDP (Optional)
  in the epct file (r14_linux_nsp5_maxi_zone1_to14_midi.epct).


Build upgrade package for step 1
--------------------------------

Since no generic upgrade packages for the upgrade path steps are currently
available, on e.g. CD/DVD, you have to build the upgrade package for this
step yourself.
These instructions, describe how to build upgrade packages on tos2.
To be able to access IO1 from tos2, a special mounting is required, which
has been done in the earlier upgrade path step 0.5.


Step 1: It is enough to use tbAD14l_4to5_smoothPrep. Add TLMs separately
        below, if any.

Open a new shell to build the upgrade package from and enter the following:
  ssh -X telorb@tos2
  Password: tsP4ever

  cd /home/dicostest/tosFiles/to14/upgradepath/step1
  rm -rf *
  cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3

  source /ipims_dicos/BS2/tbAD14l_4to5_smoothPrep/IP_CONF_INFO/EnvSettings
                                                         (including TSP4 RefApp)

  setenv EP_WORKSPACE `pwd`/epws

  epconfig delete -a

  Check if there are any TLMs to be used:
    ls -l /home/dicoshack/Hack/WP051/step1/

      If there are TLMs, then:
        epconfig set -r /home/dicoshack/Hack/WP051/step1/

  Add other TLMs, if any:
    epconfig set -r ...

  epct -d /home/dicostest/tosFiles/to14/upgradepath/step1 -XvFc -u /home/dicostest/tosFiles/to14/upgradepath/initialstart_rm453_ec3/to14_tbAD14lp11_5.config name_step1.epct r14_linux_nsp5_maxi_zone1_to14_midi.epct r14_linux_refapp_to14.epct r14_linux_vip_to14.epct r14_linux_extra_config_to14.epct

--- Start: Partial example printout (2005-10-13, 14:23) ---
 The generated upgrade package step1 consists of :

      changed IDP(s): IDP/MD14 IDP/SU1 IDP/D38 IDP/D35 IDP/D48 IDP/D2 
      created LM(s): LM/D318 LM/D270 LM/D298 LM/D329 LM/D327 LM/D330 LM/D334 LM/D356 LM/D387 LM/D283 LM/D299 LM/D333 LM/D297 LM/D390 LM/D381 LM/D386 LM/D328 LM/D305 LM/D264 LM/D304 LM/D383 LM/D340 
      changed LM: LM/AXG828 (R1S55 -> R1U12)
      changed LM: LM/D53 (R1J01 -> R1K11)
      changed LM: LM/D60 (R1K11 -> R1L11)
      changed LM: LM/D61 (R1M11 -> R1N11)
      changed LM: LM/D133 (R1T13 -> R1U11)
      changed LM: LM/D275 (R1D12 -> R1E11)
        :
      removed DUT(s): DicosFsMO_Dut.SWI_D82
--- End: Partial example printout ---

  cd /home/dicostest/tosFiles/to14/upgradepath/step1/
  ls -l
  The file "step1.config" and the directory "upgradePackages" should have been
  created.

  more /home/dicostest/tosFiles/to14/upgradepath/step1/upgradePackages/step1/upgradeConfigurationData/upgradeControlData.01
  more /home/dicostest/tosFiles/to14/upgradepath/step1/upgradePackages/step1/upgradeConfigurationData/upgradeControlData.02


Build upgrade package for step 2
--------------------------------

Since no generic upgrade packages for the upgrade path steps are currently
available, on e.g. CD/DVD, you have to build the upgrade package for this
step yourself.
These instructions, describe how to build upgrade packages on tos2.
To be able to access IO1 from tos2, a special mounting is required, which
has been done in the earlier upgrade path step 0.5.


Step 2: It is enough to use tbAD14l_4to5_redundancyPrep. Add TLMs separately
        below, if any.

Open a new shell to build the upgrade package from and enter the following:
  ssh -X telorb@tos2
  Password: tsP4ever

  cd /home/dicostest/tosFiles/to14/upgradepath/step2
  rm -rf *
  cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3

  source /ipims_dicos/BS2/tbAD14l_4to5_redundancyPrep/IP_CONF_INFO/EnvSettings
                                                         (including TSP4 RefApp)

  setenv EP_WORKSPACE `pwd`/epws

  epconfig delete -a

  Check if there are any TLMs to be used:
    ls -l /home/dicoshack/Hack/WP051/step2/

      If there are TLMs, then:
        epconfig set -r /home/dicoshack/Hack/WP051/step2/

  Add other TLMs, if any:
    epconfig set -r ...

  epct -d /home/dicostest/tosFiles/to14/upgradepath/step2 -XvFc -u /home/dicostest/tosFiles/to14/upgradepath/step1/step1.config name_step2.epct r14_linux_nsp5_maxi_zone1_to14_midi.epct r14_linux_refapp_to14.epct r14_linux_vip_to14.epct r14_linux_extra_config_to14.epct

--- Start: Partial example printout (2005-10-13, 09:35) ---
 Upgrade method: DicosRedundancyReboot caused by LM/AXG561  LM/AXG425  LM/AXG436  LM/AXG673  LM/AXG676  LM/D25  LM/D89  LM/D97  LM/D112  LM/D114  LM/D127  LM/DUO5  LM/MD47  LM/D85  LM/D86  LM/D153  LM/D178  LM/D179  LM/D180  LM/D181  LM/D182  LM/D90  LM/D108  LM/D129  LM/D212  LM/D216  LM/D232  LM/D238  LM/D250  LM/D225  LM/D239 
 Upgrade method: DicosRedundancyReboot caused by LM/AXG561  LM/AXG425  LM/AXG436  LM/AXG673  LM/AXG676  LM/D25  LM/D89  LM/D97  LM/D112  LM/D114  LM/D127  LM/DUO5  LM/MD47  LM/D85  LM/D86  LM/D153  LM/D178  LM/D179  LM/D180  LM/D181  LM/D182  LM/D90  LM/D108  LM/D129  LM/D212  LM/D216  LM/D232  LM/D238  LM/D250  LM/D225  LM/D239 
 The generated upgrade package step2 consists of :

      changed IDP(s): IDP/MD14 IDP/MD16 IDP/MD18 IDP/SU1 IDP/D38 IDP/D32 IDP/D35 IDP/D48 IDP/D2 
      changed LM: LM/AXG561 (R4C01 -> R4C11)
      changed LM: LM/AXG425 (R5C01 -> R5C12)
      changed LM: LM/AXG436 (R3B01 -> R3C11)
      changed LM: LM/AXG732 (R1Y11 -> R1Z11)
      changed LM: LM/AXG705 (R3B01 -> R3B11)
      changed LM: LM/AXG673 (R1S11 -> R1T11)
      changed LM: LM/AXG828 (R1U12 -> R1V11)
      changed LM: LM/AXG676 (R1AB11 -> R1AC11)
      changed LM: LM/AXG694 (R1Y11 -> R1Z11)
      changed LM: LM/AXG693 (R1V11 -> R1X11)
      changed LM: LM/AXG904 (R1X11 -> R1Y11)
      changed LM: LM/AXG1006 (R1Z11 -> R1AA11)
      changed LM: LM/MD37 (R2L11 -> R2M11)
      changed LM: LM/MD38 (R1Z11 -> R1AA11)
      changed LM: LM/D25 (R1M11 -> R1N11)
      changed LM: LM/D61 (R1N11 -> R1S11)
      changed LM: LM/D89 (R1L11 -> R1N11)
      changed LM: LM/D97 (R2Z11 -> R2ZB11)
      changed LM: LM/D112 (R2AC01 -> R2AD11)
      changed LM: LM/D114 (R2AB12 -> R2AE11)
      changed LM: LM/D127 (R2AC11 -> R2AE11)
      changed LM: LM/D133 (R1U11 -> R1V11)
      changed LM: LM/D270 (R2A01 -> R2B11)
      changed LM: LM/DUO5 (R1J -> R1K11)
      changed LM: LM/MD47 (R3A01 -> R3B11)
      changed LM: LM/D85 (R4C01 -> R4C02)
      changed LM: LM/D86 (R1L11 -> R1N11)
      changed LM: LM/D153 (R1N11 -> R1S11)
      changed LM: LM/D178 (R1L11 -> R1N11)
      changed LM: LM/D179 (R1L11 -> R1N11)
      changed LM: LM/D180 (R1N12 -> R1T11)
      changed LM: LM/D181 (R1M11 -> R1S11)
      changed LM: LM/D182 (R1N11 -> R1T11)
      changed LM: LM/D214 (R1F01 -> R1G11)
      changed LM: LM/D90 (R1Y13 -> R1Z11)
      changed LM: LM/D108 (R3A01 -> R3A11)
      changed LM: LM/D129 (R1G11 -> R1J11)
      changed LM: LM/D212 (R1L11 -> R1M11)
      changed LM: LM/D216 (R1G13 -> R1H11)
      changed LM: LM/D232 (R1J11 -> R1L11)
      changed LM: LM/D238 (R1E11 -> R1F11)
      changed LM: LM/D250 (R1E11 -> R1G11)
      changed LM: LM/D161 (R1C13 -> R1D11)
      changed LM: LM/D225 (R1G11 -> R1K11)
      changed LM: LM/D239 (R1D11 -> R1E11)
      changed LM: LM/D17 (R2Y12 -> R2Z11)
--- End: Partial example printout ---

  cd /home/dicostest/tosFiles/to14/upgradepath/step2
  ls -l
  The file "step2.config" and the directory "upgradePackages" should have been
  created.

  more /home/dicostest/tosFiles/to14/upgradepath/step2/upgradePackages/step2/upgradeConfigurationData/upgradeControlData.01
  more /home/dicostest/tosFiles/to14/upgradepath/step2/upgradePackages/step2/upgradeConfigurationData/upgradeControlData.02


Pack and upload the upgrade packages to IO1
-------------------------------------------
On tos2:
  cd /home/dicostest/tosFiles/to14/upgradepath/step1/upgradePackages
  tar zcf step1.tgz step1
  scp step1.tgz telorb@toXXio1:/opt/telorb/axe/upgradePackages/
  Password: tel123orb         (Adjust toXX to valid TSP system)


  cd /home/dicostest/tosFiles/to14/upgradepath/step2/upgradePackages
  tar zcf step2.tgz step2
  scp step2.tgz telorb@toXXio1:/opt/telorb/axe/upgradePackages/
  Password: tel123orb         (Adjust toXX to valid TSP system)


Unpack the upgrade packages on IO1
----------------------------------
On IO1:
  cd /opt/telorb/axe/upgradePackages
  tar zxf step1.tgz
  tar zxf step2.tgz


Apply upgrade package "step1"
-----------------------------
In TelORB Manager's "Upgrades" card, click "Rescan" and then select "step1"
and click "Apply".

Is the following OK??!!
In all Dicos processors:
DEBUG INFO: A compressed DB Backup will be generated
DEBUG INFO: "mkdir /dev" done
DEBUG INFO: "mknod -b /dev/rpc1 2 1" done
DEBUG INFO: "mknod -b /dev/rpc2 2 2" done
DEBUG INFO: "mknod -b /dev/rpc3 2 3" done
DEBUG INFO: "mkdir /loadingGroup01_1" done
DEBUG INFO: "mkdir /loadingGroup01_2" done
DEBUG INFO: "mkdir /upgradePackages" done
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc1 /loadingGroup01_1/ /opt/telorb/axe/loadingGroup01_1 " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.1.1 -o ipaddr=172.16.9.1 /dev/rpc2 /loadingGroup01_2/ /opt/telorb/axe/loadingGroup01_2 " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/telorb/axe/upgradePackages " failed; error-code = 11 (Device or resource busy)

Upgrade OK, but the TelORB manager froze for some time when I tried to list NFS
mounts" by clicking "Refresh" in the TM "DNS/NFS" card. A popup window appeared:
  "Error
   Failed to list NFS mounts"

  Disconnected and reconnected TM => it was possible to list NFS mounts in
  the TM "DNS/NFS" card.


Update IO tools on IO1 and IO2
------------------------------
On e.g. tos2:
- Copy IO tools from the distribution to IO1 and IO2:
    cd /uab/ipims_dicos/ipims_dicos10/dists/
      Also available at: ftp://ulinpc49.uab.ericsson.se/pub/UpgradePath/tools.CXP901305.R1AJ12_s3.tar
      (Previous location: /ipims_dicos/ipims_dicos10/dists/UpgradePath_4to5/tbAD14l_4to5_RT_redundancyPrep/system/unix/)

    scp tools.CXP901305.R1AJ12_s3.tar telorb@toXXio1:/opt/telorb/
    Password: tel123orb         (Adjust toXX to valid TSP system)
    scp tools.CXP901305.R1AJ12_s3.tar telorb@toXXio2:/opt/telorb/
    Password: tel123orb         (Adjust toXX to valid TSP system)

According to "TSP5 Upgrade Instruction From TSP4", 3/1531-ANA 901 04/1-1 PA3:

On IO1:
- Unpack IO tools:
    cd /opt/telorb
    tar xf tools.CXP901305.R1AJ12_s3.tar
  (codearchive.CXP901305.R1AJ12_s3 will be unpacked)

- Stop all services running on the IO (as telorb user):
    /etc/rc3.d/S88TelorbServices stop
    Password: tel123orb

- Become root:
    su -
    Password: rootroot
    cd /opt/telorb

- Remove the old codearchive directory or rename it:
    rm -fr codearchive
     -or-
    mv codearchive codearchive_tsp4_rm453_mcp3.orig

- Move the codearchive which you previously unpacked to the default
  codearchive location:
    mv codearchive.CXP901305.R1AJ12_s3 codearchive

- Execute the script prepareTeloORB.sh which will install and start all the
  services belonging to the new IO tools:
    cd /opt/telorb/codearchive/iom_scripts
    ./prepareTelORB.sh -p -c -i1
    Check the result printout, to verify that all services are running
    and also check "Current version" which should be "CXP901305.R1AJ12_s3".

    exit

- Update the /opt/OS/tar/tools.tar symlink:
    cd /opt/OS/tar
    mv /opt/telorb/tools.CXP901305.R1AJ12_s3.tar .
    ln -fs tools.CXP901305.R1AJ12_s3.tar tools.tar
    ls -l tools.tar

On IO2:
- Unpack IO tools:
    cd /opt/telorb
    tar xf tools.CXP901305.R1AJ12_s3.tar
  (codearchive.CXP901305.R1AJ12_s3 will be unpacked)

- Stop all services running on the IO (as telorb user):
    /etc/rc3.d/S88TelorbServices stop
    Password: tel123orb

- Become root:
    su -
    Password: rootroot
    cd /opt/telorb/

- Remove the old codearchive directory or rename it:
    rm -fr codearchive
     -or-
    mv codearchive codearchive_tsp4_rm453_mcp3.orig

- Move the codearchive which you previously unpacked to the default
  codearchive location:
    mv codearchive.CXP901305.R1AJ12_s3 codearchive

- Execute the script prepareTeloORB.sh which will install and start all the
  services belonging to the new IO tools:
    cd /opt/telorb/codearchive/iom_scripts
    ./prepareTelORB.sh -p -c -i2
    Check the result printout, to verify that all services are running
    and also check "Current version" which should be "CXP901305.R1AJ12_s3".

    exit

- Update the /opt/OS/tar/tools.tar symlink:
    cd /opt/OS/tar
    mv /opt/telorb/tools.CXP901305.R1AJ12_s3.tar .
    ln -fs tools.CXP901305.R1AJ12_s3.tar tools.tar
    ls -l tools.tar


Apply upgrade package "step2"
-----------------------------
In TelORB Manager's "Upgrades" card, select "step2" and click "Apply".

The upgrade was successful, but the following error dump was received in
Proc_m0_s21 during the reconfiguration of its DUs after it had been reloaded:
Why??!!

Processor: Proc_m0_s21 [1.1.9]
 Capsule abortion no 1
 TelORB time (UTC): Thu Oct 13 13:22:09 2005
 CapsuleId: 148
 CapsuleName: De2DisPT
 Reason: Could not create port

Program Error at 0067578a

Register dump:

  EAX: 00000000  ECX: 00000000  EDX: 00000000  EBX: 00000000
  ESP: a000fab4  EBP: a000fad0  ESI: 00000000  EDI: 00000000

  EIP: 0067578a  EFLAGS: 00040297

Stack dump:

  a000fab4: 1002cbfb 00000379 a000fb04 a000fb00 10197042 a0030da0 0000000c
  a000fad0: a000fc10 1001f7c7 00000379 a000fb04 a000fc10 1001f7a3 a000fb10
            00000100 219f69a0 a000fc1c a09a5010 a09a5388 a0010330 00000001
              ....  
            1002cbfb 00000033 a000fc3c a09a5010 a0010330 10022aef a09a5010
  a000fc10: a000fc60 10028590 219f69a0 a000fc3c a09a5308 a09a5168 a09a5174
            a09a5010 0000003c a09a5414 a08baff8 00000000 a0010330 a09a5010
            1002a1c0 00000000 00000150 1002f09e 1001ee50 a09a5168
  a000fc60: a000fc90 1002e259 a09a5010 00000003 1002f09e 00000028 a09a5178
            a09a5308 a09a5308 a000fcc0 1002f09e 00000150
  a000fc90: a000fcc0 1002f0a7 a09a5010 a09a5174 a000fcc0 a000fcc4 a09a5178
            a0010120 a000fcf0 109fce34 a09a5174 a09a5198
  a000fcc0: a000fcf0 109fce4b a09a5178 a09a5174 109fd419 a09a51b0 00000001
            a09a5308 a09a5308 a000fd30 109fd419 00000028
  a000fcf0: a000fd30 109fd422 a09a5168 a09a5308 0000000c 109fe8d5 a000fd84
            a09a5308 a09a51b0 109feaca a09a5198 a09a51b0 00000001 00000001
            a000fd84 a000ff20
  a000fd30: a000fda0 109fe8f5 a09a5308 a09a5198 a000fd84 109fe8de a09a5198
            a09a51b0 00000001 109fe8c1 a000fd84 a000ff20 00000030 109ffe31
              ....  
            003b5a99 00000001 00000001 00000000 00000000 00000000 a08baff8
  a000fda0: a000fdd0 1002e942 a09a5308 00000001 00000001 a000ff20 a09a51b0
            a000fe30 00000030 1001ee2b a09a5308 a0030fa8
  a000fdd0: a000fe00 1002f513 a09a51b0 a000ff20 a000fe00 1002f506 a000fe30
            a0030e28 a000fe40 109fea27 a0030e28 a000fe30

Call chain: 0067578a 1001f7c7 10028590 1002e259 1002f0a7 109fce4b 109fd422 109fe8f5 1002e942 1002f513 109fea35 10039e2e 1002a5e2 0064da6f 0065b88b

Target i486
LM/AXG561=R4C01:.text+0009b0aa
LM/AXG425=R5C01:.text+0001f7c7
LM/AXG425=R5C01:.text+00028590
LM/AXG425=R5C01:.text+0002e259
LM/AXG425=R5C01:.text+0002f0a7
LM/PRO301=R2B11:.text+0000080b
LM/PRO301=R2B11:.text+00000de2
LM/PRO301=R2B11:.text+000022b5
LM/AXG425=R5C01:.text+0002e942
LM/AXG425=R5C01:.text+0002f513
LM/PRO301=R2B11:.text+000023f5
LM/AXG425=R5C01:.text+00039e2e
LM/AXG425=R5C01:.text+0002a5e2
LM/AXG561=R4C01:.text+0007338f
LM/AXG561=R4C01:.text+000811ab

Capsule 148 "De2DisPT"
Process 148 [524298] "De2DisPT"
    Thread 32933 "" [Ready]
        Port 2636335688
        Timer 21516160, 60000 ms
        Port 2636614025
        Port 2636664558
        Timer 21513875, 60000 ms


--- Start: Old info but still valid ?---
Upgrade OK, but got the following error popup window from TelORB manager:
  "Error
   Could not get system name"
  "Error
   Failed to list NFS mounts" at "Refresh" in the TM "DNS/NFS" card. This could
   be a problem which occurred already in step1 and ought to be retested!

The LoadViewer disappears with the following printout:
Win.LM_MD45.R1L01.i486-Redhat-6.0: /uab/ipims_dicos/ipims_dicos20/BS2/tbAD14p10/Components_SA/Unix_SE/Unix_OB/Win_OU/src/win.cc:622: int ekmRead(SockData *): Assertion `sortindex >= 0' failed.

  Disconnect and reconnect TM => system name OK and it was possible to
  list NFS mounts in the TM "DNS/NFS" card.

However, when connecting the TelORB Manager, the following popup window
appeared (has been seen prior to this step):
  "Error
   Could not scan Vip NetRed devices :  System Error"

Additionally, the TelORB Manager is extremely slow.
--- End: Old info but still valid ---


Steps 1 and 2 CW/OS, NM & SS7 - Smooth upgrade, IO tools update and Redundancy upgrade
======================================================================================

Preparation if not already done
-------------------------------
- To be able to use the same epct file for upgrade package creations later on,
  make sure that
    SOFTWARE IDP/SU1;	// TelorbLinux_IDP, Linux (Optional)
  is stated before
    SOFTWARE IDP/D2;	// NetRed_IDP (Optional)
  in the epct file (telorb.conf -> telorb_step1.epct).
    cd /opt/telorb/system
    cp telorb.epct telorb_orig.epct
    Modify telorb.epct and name it telorb_step1.epct.
    cp telorb_step1.epct telorb.epct


Preparations for creation of upgrade package for step 1
-------------------------------------------------------
- On IO1, Create directories for upgrade files:
    mkdir /opt/telorb/axe/scripts
    mkdir /tmp/NM_Upgrade_step123

- If not already done,
  on WS, download the (UpgradePath_4to5.tgz) and NM_Upgrade_step123 files from
    ftp://rftp.uab.ericsson.se/pub/SysInt/TSP5_2/delivery/UpgradePath/Delivery1/Subsystem_content/CWOS and NM, respectively (Since we build the upgrade packages
using testbeds and fetch IO tools from another place, it is not necessary to
download and treat the UpgradePath_4to5.tgz file):
      cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff
      Download (both) file(s).
      Make the file(s) readable by all.
      Compare file sizes with
        /home/qperulf/data/UpgradePath_SIV/ on ulinpc249 (qperulf)

  (- On IO1, copy the UpgradePath_4to5.tgz file from WS to IO1 (takes ~10 min):
      cd /tmp
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff/UpgradePath_4to5.tgz .
    Password: tsP4ever)

- If not already done,
  on e.g. WS, download the NM_Upgrade_step123 file from
    ftp://rftp.uab.ericsson.se/pub/SysInt/TSP5_2/delivery/UpgradePath/Delivery1/Subsystem_content/NM:
      cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff
      Download.
      Make the files readable by all.
      Compare file sizes with
        /home/qperulf/data/UpgradePath_SIV/ on ulinpc249 (qperulf)


  - On IO1, copy the NM_Upgrade_step123.tgz file from WS to IO1:
      cd /tmp/NM_Upgrade_step123
      scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff/NM_Upgrade_step123.tgz .
    Password: tsP4ever

  - Extract the downloaded files:
      (cd /tmp)
      (gtar -zxvf UpgradePath_4to5.tgz)
  :  (Lots of errors, "Cannot open: No such file or directory", probably due to
  :   "gtar: scripts: Cannot mkdir: No space left on device"
  :
gtar: UpgradePath_4to5/WP073/cwos-WP073-test/installUpgrade: Cannot open: No such file or directory
UpgradePath_4to5/WP073/cwos-WP073-test/setDefaultVersion
gtar: UpgradePath_4to5/WP073/cwos-WP073-test/setDefaultVersion: Cannot open: No such file or directory
UpgradePath_4to5/WP073/cwos-WP073-test/setup.csh
gtar: UpgradePath_4to5/WP073/cwos-WP073-test/setup.csh: Cannot open: No such file or directory
UpgradePath_4to5/WP073/includedMis
gtar: UpgradePath_4to5/WP073/includedMis: Cannot open: No such file or directory
UpgradePath_4to5/WP073/name.epct
gtar: UpgradePath_4to5/WP073/name.epct: Cannot open: No such file or directory
UpgradePath_4to5/tsp45io.iso
gtar: UpgradePath_4to5/tsp45io.iso: Wrote only 0 of 10240 bytes
gtar: Unexpected EOF in archive
gtar: Error is not recoverable: exiting now

      Try to clean up:
        cd /tmp/
        \rm -rf UpgradePath_4to5
        rm -rf UpgradePath_4to5.tgz)

      cd /tmp/NM_Upgrade_step123
      gtar -zxvf NM_Upgrade_step123.tgz

  - On IO1, if not already done, create a copy of the telorb.epct and nm.epct
    files:
      cd /opt/telorb/system/
      cp telorb.epct telorb_step05.epct
      cp nm.epct nm_step05.epct

  - On IO1, modify nm.epct and name.epct for upgrade package step 1:
    cd /tmp/NM_Upgrade_step123/scripts
    ./setEpctStep1
    cd /opt/telorb/system
    cp nm.epct nm_step1.epct
    echo "NAME TSP4_to_TSP5_step1;" > name.epct


Build upgrade package for step 1
--------------------------------
Since no generic upgrade packages for the upgrade path steps are currently
available, on e.g. CD/DVD, you have to build the upgrade package for this
step yourself.
These instructions, describe how to build upgrade packages on tos2.
To be able to access IO1 from tos2, a special mounting is required, which
has been done in the earlier upgrade path step 0.5.

- Open a new shell to build the upgrade package from and enter the
  following:
    ssh -X telorb@tos2
    Password: tsP4ever

    cd /home/dicostest/tosFiles/to14/upgradepath/step1
    rm -rf *
    cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/config_files_tsp4_cwos_nm_ss7/step1
    rm -rf *

- From tos2, copy all valid epct files from IO1:
    scp telorb@to14io1:/opt/telorb/system/name.epct .
    Password: tel123orb
    scp telorb@to14io1:/opt/telorb/system/telorb.epct .
    scp telorb@to14io1:/opt/telorb/system/nm.epct .
    scp telorb@to14io1:/opt/telorb/system/SS7.epct .
    scp telorb@to14io1:/opt/telorb/system/vip.epct .
    scp telorb@to14io1:/opt/telorb/system/refapp.epct .

- Fetch .config file from the system:
    scp telorb@to14io1:/opt/telorb/axe/TSP4_to_TSP5_step05.config .

- Source and epconfig set:
    mkdir epws
    source /to14/to14io1/home/TSP-4.0-RM453-2-0/setup.csh
    setenv EP_WORKSPACE `pwd`/epws
    epconfig delete -a
    epconfig set -r /ipims_dicos/BS2/tbAD14l_4to5_smoothPrep
                                                         (including TSP4 RefApp)
    epconfig set -r /ipims_dicos/BS2/tbAD14l_4to5_smoothPrepNMSS7

  Should epconfig be set towards step05??

- Check if there are any TLMs to be used:
    ls -l /home/dicoshack/Hack/WP051/step1/

      If there are TLMs, then:
        epconfig set -r /home/dicoshack/Hack/WP051/step1/

- Add other TLMs, if any:
    epconfig set -r ...

- Build:
    epct -X -v -d /home/dicostest/tosFiles/to14/upgradepath/step1 -u TSP4_to_TSP5_step05.config name.epct telorb.epct nm.epct SS7.epct vip.epct

--- Start: Partial example printout (2005-11-11, ~18:30) ---
 The generated upgrade package TSP4_to_TSP5_step1 consists of :
      created IDP(s): IDP/NMLICENSEMANAGER IDP/NMIRPAGENT IDP/LOGGINGSP 
      changed IDP(s): IDP/MD14 IDP/SU1 IDP/D38 IDP/D35 IDP/D48 IDP/D2 IDP/PMFCORE IDP/LINUXCOMMONSERVICES IDP/JIMLDAP IDP/APACHE IDP/OMTOOLBOX IDP/FTU IDP/JXPLORER IDP/QUERYTOOL IDP/PMPLATFORMMEASURES IDP/LAD 
      removed IDP(s): IDP/cryptoServer IDP/PMFUNIX IDP/LINUXMEASURES IDP/IOMEASURES 
      created LM(s): LM/D318 LM/D270 LM/D298 LM/D329 LM/D327 LM/D330 LM/D334 LM/D356 LM/D387 LM/D283 LM/D299 LM/D333 LM/D297 LM/D390 LM/D381 LM/D386 LM/D328 LM/D305 LM/D264 LM/D304 LM/D383 LM/D340 LM/SNMPMASTER LM/EXPATLIB LM/GDBMLIB LM/NMDICOSENVMIRROR LM/NMTOOLBOX LM/NMFTUADMINISTRATOR LM/NMJXPLORER LM/NMQUERYTOOL LM/DISKMEASURES LM/CUPTIME LM/NMLIVEALARMDISPLAY LM/NMLMGUI LM/NMLMFEATUREHANDLER LM/NMLMSENTINEL LM/NMIRPAGENTPOTS LM/NMIRPA330N320 LM/NMIRPA330N330 LM/NMIRPAGENT LM/LOGGINGSP LM/MYSQLCLIENT 
      changed LM: LM/AXG828 (R1S55 -> R1U12)
      changed LM: LM/D53 (R1J01 -> R1K11)
      changed LM: LM/D60 (R1K11 -> R1L11)
      changed LM: LM/D61 (R1M11 -> R1N11)
      changed LM: LM/D133 (R1T13 -> R1U11)
      changed LM: LM/D275 (R1D12 -> R1E11)
      changed LM: LM/PMC (R5B01 -> R5B01UR1A01)
      changed LM: LM/PMNOTIFICATIONINTERCEPTOR (R5B01 -> R5B01UR1A01)
      changed LM: LM/PMFCPP (R5B01 -> R5B01UR1A01)
      changed LM: LM/PMFJAVA (R5B01 -> R5B01UR1A01)
      changed LM: LM/JIMLDAP (R6B01 -> R6B01UR1A01)
      changed LM: LM/TELORBMEASURES (R5A01 -> R5A01UR1A02)
      changed LM: LM/PMPlatformMeasuresC++ (R5A01 -> R5A01UR1A01)
      changed LM: LM/PMPlatformMeasuresJAVA (R5A01 -> R5A01UR1A01)
      removed LM(s): LM/cryptoServer LM/PMFUNIX LM/PMDiskMeasuresC++ LM/PMDiskMeasuresJAVA LM/LINUXMEASURESRPM LM/OPENSSH LM/OPENSSHCLIENT LM/IOMEASURES 
      created POT(s): DswcmKernelConfigDataPOT.SWI_AXG2536 DipIpUnitData.OU_D164 DipIpRouteData2.OU_D164 DipNetworkInterfaceData2.OU_D164 DipIpDistributorDeviceData2.OU_D164 DswProcessorSupervisionPOT.SWI_D422 CUpInteger.SWI_CUPTIME NMIRPAgentPOT.SWI_NMIRPAGENTPOT NMIRPSubscriptionPOT.SWI_NMIRPSUBSCRIPTIONPOT 
      changed POT(s): DswcmDistributionUnitType.SWI_AXG2536 DswcmDicosProcessor.SWI_AXG2536 DswcmSoftwareConfiguration.SWI_AXG2536 DswcmSwdLoadModule.SWI_AXG2536 DswcmInitialData.SWI_AXG2536 DswcmLoadingDomain.SWI_AXG2536 DswcmLoadModule.SWI_AXG2536 DswcmPersistentObjectType.SWI_AXG2536 DswcmDistributionPool.SWI_AXG2536 DswcmApplicationLoadedSwd.SWI_AXG2536 DswcmProcessorGroup.SWI_AXG2536 DswcmInternalDeliveryPackage.SWI_AXG2536 DswcmProcessorGroupReferencer.SWI_AXG2536 DswcmDeviceProcessor.SWI_AXG2536 DswcmProcessType.SWI_AXG2536 DizIpcManagementData.OU_D80 DipNetworkInterfaceData.OU_D164 DcfDistributionMappingData.OU_D164 DipIpDistributorDeviceData.OU_D164 DipIpRouteData.OU_D164 CwosNetRedVipRemoteAddress_POT.SWI_D410 CwosNetRedVip_POT.SWI_D410 
      created PT(s): DicosInterZoneIpcManagementPT.OU_D80 DicosFsMo_Pt.SWI_D82 DswProcessorSupervisionPT.SWI_D422 DeeUtilCliDaemon.OU_D300 DeeUtilGlobalRootDaemon.OU_D300 DeeUtilLocalRootDaemon.OU_D300 FileSystemCorba_PT.SWI_D407 FileServerCorba_PT.SWI_D429 NtpManagement_PT.OU_D364 EthifSupervisor_PT.OU_D370 HardwareMO_PT.OU_D382 DdbSetup_PT.OU_D399 AlarmGateway_PT.OU_D418 LinuxTzReader_PT.OU_D284 LinuxFsAgent_Pt.SWI_D409 TimeSupervisor_PT.OU_D380 OpenORBNotifSvcServer_PT.SWI_D405 DcfProcNode.OU_D427 VipOspfV3_SLAVE_PT.OU_D412 IPconfAgentPT.SWI_D470 IpConfigurator.OU_D366 VipOspfV3_MASTER_PT.SWI_D415 VipOspf_LX_SLAVE_PT.OU_D290 VipOspfV3_LX_SLAVE_PT.OU_D337 RsyncDaemonRpm_PT.OU_D414 TransferManagerRpm_PT.OU_D389 SNMP_Master_PT.OU_SNMPMASTER expatlib_PT.SWI_EXPATLIB gdbmlib_PT.SWI_GDBMLIB DicosEnvMirror_PT.SWI_NMDICOSENVMIRROR NMToolbox_PT.OU_NMTOOLBOX nmftuadministrator_PT.SWI_NMFTUADMINISTRATOR nmjxplorer_PT.OU_NMJXPLORER QueryTool_PT.OU_NMQUERYTOOL DiskMeasures.SWI_DISKMEASURES CUptime.SWI_CUPTIME LiveAlarmDisplay_PT.SWI_NMLIVEALARMDISPLAY LicenseManager_PT.SWI_NMLMGUI LMFHProc.SWI_LMFH sentinel_PT.SWI_SENTINEL NMIRPAgent.SWI_NMIRPAGENT LoggingSP.SWI_LOGGINGSP MYSQLClient.SWI_MYSQLCLIENT 
      changed PT(s): DicosDistributedIpManager.OU_D164 CwosNetRedVipPT.SWI_D410 PmPlatformMeasuresServerProcess.SWI_PMPlatformMeasuresSERVER PmPlatformMeasuresReporterProcess.SWI_PMPlatformMeasuresREPORTER PmPlatformMeasuresIntraProcess.SWI_PMPlatformMeasuresINTRA 
      removed PT(s): DicosInterZoneIpcManagement.OU_D80 DicosFsMO_Pt.SWI_D82 cryptoServer.SWI_cryptoServer PMFUnix.SWI_PMFUNIX PmDiskMeasuresServerProcess.SWI_PMDiskMeasuresSERVER PmDiskMeasuresIntraProcess.SWI_PMDiskMeasuresINTRA PmDiskMeasuresReporterProcess.SWI_PMDiskMeasuresREPORTER LinuxMeasuresRpm.SWI_LINUXMEASURESRPM OpenSSH.SWI_OPENSSH OpenSSHClient.SWI_OPENSSHCLIENT IoMeasures.SWI_IOMEASURES 
      created DUT(s): DicosFsMo_Dut.SWI_D82 DipIpUnit_DUT.OU_D164 DipIpRoute2_DUT.OU_D164 DswProcessorSupervisionPOT_DUT.SWI_D422 DswProcessorSupervisionPT_DUT.SWI_D422 DeeUtilGlobalRootDaemon_DUT.OU_D300 DeeUtilLocalRootDaemon_DUT.OU_D300 DeeUtilCliDaemon_DUT.OU_D300 FileSystemCorba_DUT.SWI_D407 FileServerCorba_DUT.SWI_D429 NtpManagement_DUT.OU_D364 EthifSupervisor_DUT.OU_D370 HardwareMO_DUT.OU_D382 DdbSetup_DUT.OU_D399 AlarmGateway_DUT.OU_D418 LinuxTzReader_DUT.OU_D284 LinuxFsAgent_Dut.SWI_D409 TimeSupervisor_DUT.OU_D380 OpenORBNotifSvcServer_DUT.SWI_D405 DcfProcNode_DUT.OU_D427 VipOspfV3_SLAVE_DUT.OU_D412 IPconfAgentDUT.SWI_D470 IpConfigurator_DUT.OU_D366 VipOspfV3_MASTER_DUT.SWI_D415 VipOspf_LX_SLAVE_DUT.OU_D290 VipOspfV3_LX_SLAVE_DUT.OU_D337 RsyncDaemonRpm_DUT.OU_D414 TransferManagerRpm_DUT.OU_D389 SNMP_Master_DUT.OU_SNMPMASTER expatlib_DUT.SWI_EXPATLIB gdbmlib_DUT.SWI_GDBMLIB DicosEnvMirror_DUT.SWI_NMDICOSENVMIRROR NMToolbox_DUT.OU_NMTOOLBOX nmftuadministrator_DUT.SWI_NMFTUADMINISTRATOR nmjxplorer_DUT.OU_NMJXPLORER QueryTool_DUT.OU_NMQUERYTOOL DiskMeasuresDUT.SWI_DISKMEASURES CUpIntegerDUT.SWI_CUPTIME CUptimeDUT.SWI_CUPTIME LiveAlarmDisplay_DUT.SWI_NMLIVEALARMDISPLAY LicenseManager_DUT.SWI_NMLMGUI LMFHProc_DUT.SWI_LMFH sentinel_DUT.SWI_SENTINEL NMIRPSubscriptionDUT.SWI_NMIRPSUBSCRIPTIONPOT NMIRPAgentDUT.SWI_NMIRPAGENTPOT NMIRPAgent_DUT.SWI_NMIRPAGENT LoggingSP_DUT.SWI_LOGGINGSP MYSQLClient_DUT.SWI_MYSQLCLIENT 
      changed DUT(s): DswcmProcessorGroupDut.SWI_AXG2536 DswcmDeviceProcessorDut.SWI_AXG2536 DswcmStringKeyedPots.SWI_AXG2536 DswcmDistributionUnitTypeDut.SWI_AXG2536 DswcmDicosProcessorDut.SWI_AXG2536 DswcmApplicationLoadedSwdDut.SWI_AXG2536 DicosInterZoneIpcManagement_DUT.OU_D80 DizIpcManagementData_DUT.OU_D80 DipIpRoute_DUT.OU_D164 DipNetworkInterface_DUT.OU_D164 DipIpDistributorDevice_DUT.OU_D164 DicosDistributedIpManager_DUT.OU_D164 DcfDistributionMappingData_DUT.OU_D164 CwosNetRedVip_DUT.SWI_D410 CwosNetRedVip_POT_DUT.SWI_D410 PmPlatformMeasuresServerProcessDUT.SWI_PMPlatformMeasuresSERVER PmPlatformMeasuresIntraProcessDUT.SWI_PMPlatformMeasuresINTRA PmPlatformMeasuresReporterProcessDUT.SWI_PMPlatformMeasuresREPORTER 
      removed DUT(s): DicosFsMO_Dut.SWI_D82 cryptoServerDUT.SWI_cryptoServer PMFUnix_DUT.SWI_PMFUNIX PmDiskMeasuresServerProcessDUT.SWI_PMDiskMeasuresSERVER PmDiskMeasuresReporterProcessDUT.SWI_PMDiskMeasuresREPORTER PmDiskMeasuresIntraProcessDUT.SWI_PMDiskMeasuresINTRA LinuxMeasuresRpm_DUT.SWI_LINUXMEASURESRPM OpenSSH_DUT.SWI_OPENSSH OpenSSHClient_DUT.SWI_OPENSSHCLIENT IoMeasures_DUT.SWI_IOMEASURES 
      removed POOL(s): cryptoPool IoMeasuresPool 
      POOL(s) added to Processor(s): Proc_m1_s11 Proc_m3_s11 Proc_m1_s13 Proc_m2_s13 Proc_m0_s15 Proc_m3_s13 Proc_m1_s15 Proc_m2_s15 Proc_m0_s17 Proc_m3_s15 Proc_m1_s17 Proc_m2_s17 Proc_m0_s19 Proc_m3_s17 Proc_m1_s19 Proc_m2_s19 Proc_m3_s19 Proc_m3_s1 Proc_m1_s5 Proc_m3_s5 Proc_m3_s7 Proc_m3_s9 Proc_m2_s21 Proc_m3_s21 Proc_m0_s1 Proc_m0_s5 
**********************************************************
epct: generating /home/dicostest/tosFiles/to14/upgradepath/step1/TSP4_to_TSP5_step1.config
--- End: Partial example printout ---

  cd /home/dicostest/tosFiles/to14/upgradepath/step1
  ls -l
  The file "TSP4_to_TSP5_step1.config" and the directory "upgradePackages"
  should have been created.

  more /home/dicostest/tosFiles/to14/upgradepath/step1/upgradePackages/TSP4_to_TSP5_step1/upgradeConfigurationData/upgradeControlData.01
  more /home/dicostest/tosFiles/to14/upgradepath/step1/upgradePackages/TSP4_to_TSP5_step1/upgradeConfigurationData/upgradeControlData.02

- On tos2, pack and send the upgrade package to IO1:
    cd /home/dicostest/tosFiles/to14/upgradepath/step1/upgradePackages
    tar zcf TSP4_to_TSP5_step1.tgz TSP4_to_TSP5_step1
    scp TSP4_to_TSP5_step1.tgz telorb@to14io1:/opt/telorb/axe/upgradePackages/.
    Password: tel123orb

- On IO1, extract the upgrade package:
    cd /opt/telorb/axe/upgradePackages
    tar zxf TSP4_to_TSP5_step1.tgz


Preparations for creation of upgrade package for step 2
-------------------------------------------------------
- On IO1, modify name.epct for upgrade package step 2:
    cd /opt/telorb/system
    echo "NAME TSP4_to_TSP5_step2;" > name.epct


Build upgrade package for step 2
--------------------------------
Since no generic upgrade packages for the upgrade path steps are currently
available, on e.g. CD/DVD, you have to build the upgrade package for this
step yourself.
These instructions, describe how to build upgrade packages on tos2.
To be able to access IO1 from tos2, a special mounting is required, which
has been done in the earlier upgrade path step 0.5.

- Open a new shell to build the upgrade package from and enter the
  following:
    ssh -X telorb@tos2
    Password: tsP4ever

    cd /home/dicostest/tosFiles/to14/upgradepath/step2
    rm -rf *
    cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/config_files_tsp4_cwos_nm_ss7/step2
    rm -rf *

- From tos2, copy all valid epct files from IO1:
    scp telorb@to14io1:/opt/telorb/system/name.epct .
    Password: tel123orb
    scp telorb@to14io1:/opt/telorb/system/telorb.epct .
    scp telorb@to14io1:/opt/telorb/system/nm.epct .
    scp telorb@to14io1:/opt/telorb/system/SS7.epct .
    scp telorb@to14io1:/opt/telorb/system/vip.epct .
    scp telorb@to14io1:/opt/telorb/system/refapp.epct .

- Fetch .config file from the previous build of step 1:
    cp /home/dicostest/tosFiles/to14/upgradepath/step1/TSP4_to_TSP5_step1.config .

- Source and epconfig set:
    mkdir epws
    source /to14/to14io1/home/TSP-4.0-RM453-2-0/setup.csh
    setenv EP_WORKSPACE `pwd`/epws
    epconfig delete -a
    epconfig set -r /ipims_dicos/BS2/tbAD14l_4to5_smoothPrep
                                                         (including TSP4 RefApp)
    epconfig set -r /ipims_dicos/BS2/tbAD14l_4to5_smoothPrepNMSS7
    epconfig set -r /ipims_dicos/BS2/tbAD14l_4to5_redundancyPrep

- Check if there are any TLMs to be used:
    ls -l /home/dicoshack/Hack/WP051/step2/

      If there are TLMs, then:
        epconfig set -r /home/dicoshack/Hack/WP051/step1/

- Add other TLMs, if any:
    epconfig set -r ...

- Build:
    epct -X -v -d /home/dicostest/tosFiles/to14/upgradepath/step2 -u TSP4_to_TSP5_step1.config name.epct telorb.epct nm.epct SS7.epct vip.epct

--- Start: Partial example printout (2005-11-14, ~10:16) ---
 Upgrade method: DicosRedundancyReboot caused by LM/AXG561  LM/AXG425  LM/AXG436  LM/AXG673  LM/AXG676  LM/D25  LM/D89  LM/D97  LM/D112  LM/D114  LM/D127  LM/DUO5  LM/MD47  LM/D85  LM/D86  LM/D153  LM/D178  LM/D179  LM/D180  LM/D181  LM/D182  LM/D90  LM/D108  LM/D129  LM/D212  LM/D216  LM/D232  LM/D238  LM/D250  LM/D225  LM/D239 
 The generated upgrade package TSP4_to_TSP5_step2 consists of :

      changed IDP(s): IDP/MD14 IDP/MD16 IDP/MD18 IDP/SU1 IDP/D38 IDP/D32 IDP/D35 IDP/D48 IDP/D2 
      changed LM: LM/AXG561 (R4C01 -> R4C11)
      changed LM: LM/AXG425 (R5C01 -> R5C12)
      changed LM: LM/AXG436 (R3B01 -> R3C11)
      changed LM: LM/AXG732 (R1Y11 -> R1Z11)
      changed LM: LM/AXG705 (R3B01 -> R3B11)
      changed LM: LM/AXG673 (R1S11 -> R1T11)
      changed LM: LM/AXG828 (R1U12 -> R1V11)
      changed LM: LM/AXG676 (R1AB11 -> R1AC11)
      changed LM: LM/AXG694 (R1Y11 -> R1Z11)
      changed LM: LM/AXG693 (R1V11 -> R1X11)
      changed LM: LM/AXG904 (R1X11 -> R1Y11)
      changed LM: LM/AXG1006 (R1Z11 -> R1AA11)
      changed LM: LM/MD37 (R2L11 -> R2M11)
      changed LM: LM/MD38 (R1Z11 -> R1AA11)
      changed LM: LM/D25 (R1M11 -> R1N11)
      changed LM: LM/D61 (R1N11 -> R1S11)
      changed LM: LM/D89 (R1L11 -> R1N11)
      changed LM: LM/D97 (R2Z11 -> R2ZB11)
      changed LM: LM/D112 (R2AC01 -> R2AD11)
      changed LM: LM/D114 (R2AB12 -> R2AE11)
      changed LM: LM/D127 (R2AC11 -> R2AE11)
      changed LM: LM/D133 (R1U11 -> R1V11)
      changed LM: LM/D270 (R2A01 -> R2B11)
      changed LM: LM/DUO5 (R1J -> R1K11)
      changed LM: LM/MD47 (R3A01 -> R3B11)
      changed LM: LM/D85 (R4C01 -> R4C02)
      changed LM: LM/D86 (R1L11 -> R1N11)
      changed LM: LM/D153 (R1N11 -> R1S11)
      changed LM: LM/D178 (R1L11 -> R1N11)
      changed LM: LM/D179 (R1L11 -> R1N11)
      changed LM: LM/D180 (R1N12 -> R1T11)
      changed LM: LM/D181 (R1M11 -> R1S11)
      changed LM: LM/D182 (R1N11 -> R1T11)
      changed LM: LM/D214 (R1F01 -> R1G11)
      changed LM: LM/D90 (R1Y13 -> R1Z11)
      changed LM: LM/D108 (R3A01 -> R3A11)
      changed LM: LM/D129 (R1G11 -> R1J11)
      changed LM: LM/D212 (R1L11 -> R1M11)
      changed LM: LM/D216 (R1G13 -> R1H11)
      changed LM: LM/D232 (R1J11 -> R1L11)
      changed LM: LM/D238 (R1E11 -> R1F11)
      changed LM: LM/D250 (R1E11 -> R1G11)
      changed LM: LM/D161 (R1C13 -> R1D11)
      changed LM: LM/D225 (R1G11 -> R1K11)
      changed LM: LM/D239 (R1D11 -> R1E11)
      changed LM: LM/D17 (R2Y12 -> R2Z11)
      changed POT(s): DipIpUnitData.OU_D164 DipIpRouteData2.OU_D164 DipNetworkInterfaceData.OU_D164 DcfDistributionMappingData.OU_D164 DipNetworkInterfaceData2.OU_D164 DipIpDistributorDeviceData.OU_D164 DipIpDistributorDeviceData2.OU_D164 DipIpRouteData.OU_D164 VipOspfConfiguration.OU_D186 
      changed PT(s): DicosDistributedIpManager.OU_D164 DeeUtilCliDaemon.OU_D300 DeeUtilGlobalRootDaemon.OU_D300 DeeUtilLocalRootDaemon.OU_D300 
      changed DUT(s): DipIpRoute_DUT.OU_D164 DipIpUnit_DUT.OU_D164 DipIpRoute2_DUT.OU_D164 DipNetworkInterface_DUT.OU_D164 DipIpDistributorDevice_DUT.OU_D164 DicosDistributedIpManager_DUT.OU_D164 DcfDistributionMappingData_DUT.OU_D164 DeeUtilGlobalRootDaemon_DUT.OU_D300 DeeUtilLocalRootDaemon_DUT.OU_D300 DeeUtilCliDaemon_DUT.OU_D300 VipOspfConfiguration_DUT.OU_D186 DicosKernel_DUT.LM_AXG561 ProcessSupport_DUT.LM_AXG425 Database_DUT.LM_AXG436 ConfigManagerAgent_DUT.LM_AXG673 ConfigurationManagerControl_DUT.LM_AXG676 EarlyBaseReader_DUT.LM_D25 DcfServicesRegisterDriver_DUT.LM_D89 DcfEventService_DUT.LM_D97 DcfTransportService_DUT.LM_D112 DcfSocketGroupRegister_DUT.LM_D114 IpDistributionFunctions_DUT.LM_D127 CommLinkEthAdaptionDrv_DUT.LM_DUO5 JavaVM_DUT.LM_MD47 LinuxBasicLibrary_DUT.LM_D85 TIPC_DUT.LM_D86 TspScripts_DUT.LM_D153 DcfServicesRegisterDriver2_DUT.LM_D178 DcfEventService2_DUT.LM_D179 DcfSocketGroupRegister2_DUT.LM_D180 IpDistributionFunctions2_DUT.LM_D181 DcfTransportService2_DUT.LM_D182 LinuxJavaDpiAdaption_DUT.LM_D90 IP_UserCoordinator_DUT.LM_D108 i4DistributorDevice_DUT.LM_D129 IpUnitPopulator_DUT.LM_D212 IpUnitDistributor_DUT.LM_D216 IP_UserAgent_DUT.LM_D232 IpPortIdService_DUT.LM_D238 IpPortIdSegmentDistributor_DUT.LM_D250 IPUC_DUT.LM_D225 IpPortIdService2_DUT.LM_D239 
**********************************************************
epct: generating /home/dicostest/tosFiles/to14/upgradepath/step2/TSP4_to_TSP5_step2.config
--- End: Partial example printout ---

  cd /home/dicostest/tosFiles/to14/upgradepath/step2
  ls -l
  The file "TSP4_to_TSP5_step2.config" and the directory "upgradePackages"
  should have been created.

  more /home/dicostest/tosFiles/to14/upgradepath/step2/upgradePackages/TSP4_to_TSP5_step2/upgradeConfigurationData/upgradeControlData.01
  more /home/dicostest/tosFiles/to14/upgradepath/step2/upgradePackages/TSP4_to_TSP5_step2/upgradeConfigurationData/upgradeControlData.02

- On tos2, pack and send the upgrade package to IO1:
    cd /home/dicostest/tosFiles/to14/upgradepath/step2/upgradePackages
    tar zcf TSP4_to_TSP5_step2.tgz TSP4_to_TSP5_step2
    scp TSP4_to_TSP5_step2.tgz telorb@to14io1:/opt/telorb/axe/upgradePackages/.
    Password: tel123orb

- On IO1, extract the upgrade package:
    cd /opt/telorb/axe/upgradePackages
    tar zxf TSP4_to_TSP5_step2.tgz


Apply upgrade package "TSP4_to_TSP5_step1"
------------------------------------------
In TelORB Manager's "Upgrades" card, click "Rescan" and then select
"TSP4_to_TSP5_step1" and click "Apply".

Observation: Is the following OK??!!
Only two notifications appart from lots of "PmIntraProc..." and "PmServer-4000"
notifications were received, i.e.
- System Upgrade Started
- Backup Finished Successfully

I.e. the following notifications were missing:
- System Upgrade Finished Successfully
- Backup Started

Proc_m0_s9:
LOG_ERR: DoamNotConsumerHandler.cc:161 [OU/MD37 R1G10] Notification subscriber id 6569 has too many pending [41] notifications. Notification not sent
LOG_ERR: DoamNotConsumerHandler.cc:161 [OU/MD37 R1G10] Notification subscriber id 6569 has too many pending [41] notifications. Notification not sent
LOG_ERR: DoamNotConsumerHandler.cc:161 [OU/MD37 R1G10] Notification subscriber id 6569 has too many pending [41] notifications. Notification not sent
LOG_ERR: DoamNotConsumerHandler.cc:161 [OU/MD37 R1G10] Notification subscriber id 6569 has too many pending [41] notifications. Notification not sent
LOG_ERR: DoamNotConsumerHandler.cc:161 [OU/MD37 R1G10] Notification subscriber id 6569 has too many pending [41] notifications. Notification not sent
DEBUG INFO: DicosOaM: TRANSIENT (re)subscriber IOR:010000002600000049444c3a4469636f734f614d2f4e6f74696669636174696f6e436f6e73756d65723a312e30000000030000000000000030000000010101000d0000003137322e33302e31342e31340000a67710000000000000043f049c3b0100102000000065000000000000000030000000010101000d0000003137322e31362e382e31333700007a7610000000000000043f049c3b0100102000000065000000000000000030000000010101000b0000003137322e31362e302e3900007a76000010000000000000043f049c3b010010200000006500000000
  :
DEBUG INFO: DoamAlarmConsumerHandler::existent()  consumerPtrM = 2685130908
DEBUG INFO: DoamAlarmConsumerHandler::existent()  consumerPtrM = 2685120820
DEBUG INFO: DoamAlarmConsumerHandler::existent()  consumerPtrM = 2685116892
DEBUG INFO: DoamAlarmConsumerHandler::existent()  consumerPtrM = 2685114196
DEBUG INFO: DoamNotConsumerHandler::non_existent_excep CORBA::OBJECT_NOT_EXIST, [3282]
DEBUG INFO: DoamNotConsumerHandler: will remove subscriber IOR:010000002600000049444c3a4469636f734f614d2f4e6f74696669636174696f6e436f6e73756d65723a312e30000000030000000000000030000000010101000d0000003137322e33302e31342e31340000a677100000000000000442096f9c0100100f00000064000000000000000030000000010101000d0000003137322e31362e382e31333700007a76100000000000000442096f9c0100100f00000064000000000000000030000000010101000b0000003137322e31362e302e3900007a760000100000000000000442096f9c0100100f0000006400000000
  :
IIOP_Gateway: connect (defered) failed, rc = -61
IIOP_Gateway: connect (defered) failed, rc = -61
IIOP_Gateway: connect (defered) failed, rc = -61
IIOP_Gateway: connect (defered) failed, rc = -61
IIOP_Gateway: connect (defered) failed, rc = -61
LOG_ERR: DorbIiopClientPeer.cc:477 [SCC/D92 R2A08] DorbIiopClientPeer 0xa0046ed8 handleConnectAsync(). NOT OK, none in address list available, ip addr 218632364
IIOP_Gateway: connect (defered) failed, rc = -61
IIOP_Gateway: connect (defered) failed, rc = -61
IIOP_Gateway: connect (defered) failed, rc = -61
LOG_ERR: DorbIiopClientPeer.cc:477 [SCC/D92 R2A08] DorbIiopClientPeer 0xa0045888 handleConnectAsync(). NOT OK, none in address list available, ip addr 218632364
IIOP_Gateway: connect (defered) failed, rc = -61
LOG_ERR: DorbIiopClientPeer.cc:477 [SCC/D92 R2A08] DorbIiopClientPeer 0xa0044ff8 handleConnectAsync(). NOT OK, none in address list available, ip addr 218632364
IIOP_Gateway: connect (defered) failed, rc = -61
LOG_ERR: DorbIiopClientPeer.cc:477 [SCC/D92 R2A08] DorbIiopClientPeer 0xa0044768 handleConnectAsync(). NOT OK, none in address list available, ip addr 218632364
  :
DEBUG INFO: CORBA::Object::AsyncPort::handleRejectedNamed try connect to rtid: 616940, reason = 2001
DEBUG INFO: DoamNotConsumerHandler::non_existent_excep CORBA::COMM_FAILURE, [97]
DEBUG INFO: DoamNotConsumerHandler::non_existent_excep CORBA::COMM_FAILURE, [3337]
DEBUG INFO: DoamNotConsumerHandler::non_existent_excep CORBA::COMM_FAILURE, [3344]
DEBUG INFO: DoamNotConsumerHandler::non_existent_excep CORBA::COMM_FAILURE, [3345]
  :
LOG_ERR: ALARM: [type=2, severity=5, key=(LOGGING, Application=Alarm, 0), cause=Lost connection to server during query, time=2005-11-14 10:46:08]
  :
---> DdbCmaSchemaEvolutionProtocol::endDbu: FallForward
DEBUG INFO: DdbCmaSchemaEval::endDbu: classes evolved=4 instances evolved=19
DUGA: Got END_OF_CHANGE  ...
PtClassLoader: closing. myRtid = 585192 Obj=se.ericsson.telorb.internal.PtClassLoader@e4f7e
-----> Software Upgrade succeeded
LOG_NOTICE: NOTIFICATION: [type=8, objectType=upgrade, instance=, notificationId=237, time=2005-11-14 10:46:13]
LOG_ERR: DoamNotConsumerHandler.cc:161 [OU/MD37 R1G10] Notification subscriber id 6569 has too many pending [41] notifications. Notification not sent
******* ResourceAdaptor:  Generate backup with operation generate
LOG_NOTICE: NOTIFICATION: [type=16, objectType=backup, instance=, notificationId=238, time=2005-11-14 10:46:13]
LOG_ERR: DoamNotConsumerHandler.cc:161 [OU/MD37 R1G10] Notification subscriber id 6569 has too many pending [41] notifications. Notification not sent

Proc_m1_s9:
DEBUG INFO: SS7Message::handleErrorInd(): OAM_ERROR_IND received: instanceType: 1, instanceID: 1, errorCode: 19006, state: 1, eventType: 1, event: 18
DEBUG INFO: SS7Message::handleErrorInd(): OAM_ERROR_IND received: instanceType: 1, instanceID: 2, errorCode: 19006, state: 1, eventType: 1, event: 18
DEBUG INFO: SS7Message::handleErrorInd(): OAM_ERROR_IND received: instanceType: 1, instanceID: 1, errorCode: 19006, state: 1, eventType: 1, event: 18
DEBUG INFO: SS7Message::handleErrorInd(): OAM_ERROR_IND received: instanceType: 1, instanceID: 1, errorCode: 19006, state: 1, eventType: 1, event: 18
DEBUG INFO: SS7Message::handleErrorInd(): OAM_ERROR_IND received: instanceType: 1, instanceID: 2, errorCode: 19006, state: 1, eventType: 1, event: 18


Observation: Is the following OK??!!
In all Dicos processors:
PlatformMeasures Intra Started Successfully
OamProvisioningCounter Intra Started Successfully
org.omg.CORBA.COMM_FAILURE:   minor code: 0 completed: Maybe
	at se.ericsson.telorb.CORBA.diop.DIOPConnection.purge_calls(DIOPConnection.java:614)
	at se.ericsson.telorb.CORBA.diop.DIOPConnection.processConnectionDeath(DIOPConnection.java:461)
DEBUG INFO: Pm_J_Error   --> (0x2ee880) PmConfigHandler::ConfigRegisterThread::run() - Exceptions when looking for PmServer. Try again in 3 seconds.
org.omg.CORBA.COMM_FAILURE:   minor code: 0 completed: Maybe
	at se.ericsson.telorb.CORBA.diop.DIOPConnection.purge_calls(DIOPConnection.java:614)
	at se.ericsson.telorb.CORBA.diop.DIOPConnection.processConnectionDeath(DIOPConnection.java:461)
DEBUG INFO: Pm_J_Error   --> (0x2232c6) PmConfigHandler::ConfigRegisterThread::run() - Exceptions when looking for PmServer. Try again in 3 seconds.
VipOspf: processor 8: gw 192.168.76.1 available at processor 6
-----> Total functionality started.
IPC Adaptation driver: Received command
---setMaxDynamic 0
VipOspf: processor 8: gw 192.168.77.2 available
DEBUG INFO: "mkdir /dev" done
DEBUG INFO: "mknod -b /dev/rpc1 2 1" done
DEBUG INFO: "mknod -b /dev/rpc2 2 2" done
DEBUG INFO: "mknod -b /dev/rpc3 2 3" done
DEBUG INFO: "mknod -b /dev/rpc6 2 6" done
DEBUG INFO: "mknod -b /dev/rpc7 2 7" done
DEBUG INFO: "mknod -b /dev/rpc8 2 8" done
DEBUG INFO: "mknod -b /dev/rpc9 2 9" done
DEBUG INFO: "mkdir /opt" done
DEBUG INFO: "mkdir /opt/telorb" done
DEBUG INFO: "mkdir /opt/telorb/axe" done
DEBUG INFO: "mkdir /opt/telorb/axe/applog" done
DEBUG INFO: "mkdir /opt/telorb/axe/mysql-data" done
DEBUG INFO: "mkdir /loadingGroup01_1" done
DEBUG INFO: "mkdir /loadingGroup01_2" done
DEBUG INFO: "mkdir /upgradePackages" done
DEBUG INFO: "mkdir /reporterLogs" done
DEBUG INFO: "mkdir /reporterLogs2" done
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc7 /opt/telorb/axe/applog/ /opt/telorb/axe/applog " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc9 /opt/telorb/axe/mysql-data/ /opt/telorb/axe/mysql-data " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc1 /loadingGroup01_1/ /opt/telorb/axe/loadingGroup01_1 " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.1.1 -o ipaddr=172.16.9.1 /dev/rpc2 /loadingGroup01_2/ /opt/telorb/axe/loadingGroup01_2 " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/telorb/axe/upgradePackages " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc6 /reporterLogs/ /opt/telorb/axe/reporterLogs " failed; error-code = 11 (Device or resource busy)
LOG_ERR: DfsDb.cc:92 [SCC/D83 R1A27] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.9.1 -o ipaddr=172.16.1.1 /dev/rpc8 /reporterLogs2/ /opt/telorb/axe/reporterLogs2 " failed; error-code = 11 (Device or resource busy)
---> DdbCmaSchemaEvolutionProtocol::endDbu: FallForward
DEBUG INFO: DdbCmaSchemaEval::endDbu: classes evolved=4 instances evolved=58
DUGA: Got END_OF_CHANGE  ...
PtClassLoader: closing. myRtid = 616934 Obj=se.ericsson.telorb.internal.PtClassLoader@46268
PtClassLoader: closing. myRtid = 616239 Obj=se.ericsson.telorb.internal.PtClassLoader@725454
PtClassLoader: closing. myRtid = 585192 Obj=se.ericsson.telorb.internal.PtClassLoader@6297b3
PtClassLoader: closing. myRtid = 1003291 Obj=se.ericsson.telorb.internal.PtClassLoader@412939
Adding 1131961580 and keeping StartTime 1131705937: [Normal(local)]: 166479428
Shifting out StartTime 1131700884: [Normal(local)]: 3279822
DEBUG INFO: A compressed DB Backup will be generated

Observation: Is the following OK??!!
In one Dicos SS7 processor (Proc_m0_s21):
DEBUG INFO: 	 ErrorCode: 19006
DEBUG INFO: 	 ErrorCode: 19006
DEBUG INFO: 	 ErrorCode: 19006
DEBUG INFO: 	 ErrorCode: 19006
DEBUG INFO: 	 ErrorCode: 19006
DEBUG INFO: 	 ErrorCode: 19006
DEBUG INFO: 	 ErrorCode: 19006


Upgrade OK, but the TelORB manager froze for some time when I tried to list NFS
mounts" by clicking "Refresh" in the TM "DNS/NFS" card. A popup window appeared:
  "Error
   Failed to list NFS mounts"

  Disconnected and reconnected TM => it was possible to list NFS mounts in
  the TM "DNS/NFS" card.


Update IO tools on IO1 and IO2
------------------------------
*** Start: Mount point test of problem ID 40.13 ***
On IO1:
cd
pwd
  /home/telorb

mkdir opt
cd opt/
mkdir telorb
cd telorb/
pwd
  /home/telorb/opt/telorb

mount
/dev/sda8 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/sda1 on /boot type ext2 (rw)
/dev/sda6 on /home type ext2 (rw)
/dev/sda7 on /opt type ext2 (rw)
/dev/sda5 on /opt/telorb type ext2 (rw)
/dev/sda11 on /var type ext2 (rw)
/dev/sda9 on /var/log type ext2 (rw)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
automount(pid704) on /misc type autofs (rw,fd=5,pgrp=704,minproto=2,maxproto=3)

cd
pwd
  /home/telorb

su
Password: 
pwd
  /home/telorb

mount -t nfs 134.138.186.249:/export/home/qperulf/telorb/opt/telorb /home/telorb/opt/telorb/
mount
/dev/sda8 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/sda1 on /boot type ext2 (rw)
/dev/sda6 on /home type ext2 (rw)
/dev/sda7 on /opt type ext2 (rw)
/dev/sda5 on /opt/telorb type ext2 (rw)
/dev/sda11 on /var type ext2 (rw)
/dev/sda9 on /var/log type ext2 (rw)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
automount(pid704) on /misc type autofs (rw,fd=5,pgrp=704,minproto=2,maxproto=3)
134.138.186.249:/export/home/qperulf/telorb/opt/telorb on /home/telorb/opt/telorb type nfs (rw,addr=134.138.186.249)

ls -l /home/telorb/opt/telorb
total 4
-rw-r--r--    1 61115    33              7 Oct 13 15:46 test.txt

exit
*** End: Mount point test of problem ID 40.13. Continues after IO tools upgrade ***

On IO1:
- Create backups of the codearchive and etc directories:
    cd /opt/telorb
    cp -r codearchive codearchive_20051114
    cp -r etc etc_20051114

On tos2:
- Copy the IO tools package from the distribution to IO1 and IO2:
    cd /ipims_dicos/ipims_dicos10/dists/UpgradePath_w45/tbAD14l_4to5_RT_redundancyPrep/system/unix
                                                          (Adjust to valid path)
      (Previously available at:
       ftp://ulinpc49.uab.ericsson.se/pub/UpgradePath/tools.CXP901305.R1AJ12_s3.tar
       -or-
       /ipims_dicos/ipims_dicos10/dists/UpgradePath_4to5/tbAD14l_4to5_RT_redundancyPrep/system/unix/)

    scp tools.CXP901305.R50BA01.tar telorb@to14io1:/opt/telorb/.
    Password: tel123orb
    scp tools.CXP901305.R50BA01.tar telorb@to14io2:/opt/telorb/.

Upgrade the TelORB IO processor software in IO1 and IO2 according to
"TSP5 Upgrade Instruction From TSP4", 3/1531-ANA 901 04/1-1 PA5.9, as follows:

On IO1:
- Extract the IO tools package:
    cd /opt/telorb
    tar xf tools.CXP901305.R50BA01.tar
      (codearchive.CXP901305.R50BA01 will be unpacked)

- Become root: 
    su -
    Password: rootroot

- Stop all services running on the IO (as telorb user):
    /etc/rc3.d/S88TelorbServices stop

- Remove the old codearchive directory:
    cd /opt/telorb
    rm -fr codearchive

- Move the codearchive which you previously unpacked to the default
  codearchive location:
    mv codearchive.CXP901305.R50BA01 codearchive

- Execute the script prepareTeloORB.sh which will install and start all the
  services belonging to the new IO tools:
    cd /opt/telorb/codearchive/iom_scripts
    ./prepareTelORB.sh -p -c -i1
    Check the result printout, to verify that all services are running
    and also check "Current version" which should be "CXP901305.R50BA01".
    exit

- Update the /opt/OS/tar/tools.tar symlink:
    cd /opt/OS/tar
    mv /opt/telorb/tools.CXP901305.R50BA01.tar .
    ln -fs tools.CXP901305.R50BA01.tar tools.tar
    ls -l tools.tar (Verify link: tools.tar -> tools.CXP901305.R50BA01.tar)

*** Start: Michel test ***
- Verify mountings:
    mount
      Should be included: `/dev/sda5 on /opt/mirror type ext2 (rw)'
    ls -l /opt/telorb
    ls -l /opt/mirror
      Verify that the ls commands above show the same directories and files.
*** End: Michel test ***


On IO2:
- Extract the IO tools package:
    cd /opt/telorb
    tar xf tools.CXP901305.R50BA01.tar
      (codearchive.CXP901305.R50BA01 will be unpacked)

- Become root: 
    su -
    Password: rootroot

- Stop all services running on the IO (as telorb user):
    /etc/rc3.d/S88TelorbServices stop

- Remove the old codearchive directory:
    cd /opt/telorb
    rm -fr codearchive

- Move the codearchive which you previously unpacked to the default
  codearchive location:
    mv codearchive.CXP901305.R50BA01 codearchive

- Check that the configuration file /opt/telorb/etc/telorb.conf is still valid:
    less /opt/telorb/etc/telorb.conf

- Execute the script prepareTeloORB.sh which will install and start all the
  services belonging to the new IO tools:
    cd /opt/telorb/codearchive/iom_scripts
    ./prepareTelORB.sh -p -c -i2
    Check the result printout, to verify that all services are running
    and also check "Current version" which should be "CXP901305.R50BA01".
    exit

- Update the /opt/OS/tar/tools.tar symlink:
    cd /opt/OS/tar
    mv /opt/telorb/tools.CXP901305.R50BA01.tar .
    ln -fs tools.CXP901305.R50BA01.tar tools.tar
    ls -l tools.tar (Verify link: tools.tar -> tools.CXP901305.R50BA01.tar)

*** Start: Michel test ***
- Verify mountings:
    mount
      Should be included: `/dev/sda5 on /opt/mirror type ext2 (rw)'
    ls -l /opt/telorb
    ls -l /opt/mirror
      Verify that the ls commands above show the same directories and files.
*** End: Michel test ***

*** Start: Mount point test of problem ID 40.13 ***
On IO1:
mount
/dev/sda8 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/sda1 on /boot type ext2 (rw)
/dev/sda6 on /home type ext2 (rw)
/dev/sda7 on /opt type ext2 (rw)
/dev/sda5 on /opt/telorb type ext2 (rw)
/dev/sda11 on /var type ext2 (rw)
/dev/sda9 on /var/log type ext2 (rw)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
automount(pid704) on /misc type autofs (rw,fd=5,pgrp=704,minproto=2,maxproto=3)
134.138.186.249:/export/home/qperulf/telorb/opt/telorb on /home/telorb/opt/telorb type nfs (rw,addr=134.138.186.249)

Missing mount point above: `/dev/sda5 on /opt/mirror type ext2 (rw)'!!!

ls -l /opt/telorb/
total 308
drwxrwxr-x    8 telorb   telorb       4096 Nov 11 15:04 axe
drwxrwxr-x    7 telorb   telorb       4096 Nov 14 14:02 codearchive
drwxrwxr-x    7 telorb   telorb       4096 Nov 14 12:59 codearchive_20051114
drwxrwxr-x    7 telorb   telorb       4096 Nov  3 11:10 codearchive_B4_CM453_MCP1
drwxrwxr-x    2 telorb   telorb       4096 Nov 11 11:07 config
drwxrwxr-x    2 telorb   telorb       4096 Nov 14 14:06 consolelogs
drwxrwxr-x    3 telorb   telorb       4096 Nov  3 17:07 crashcollector
drwxrwxr-x    2 telorb   telorb       4096 Oct 21 12:36 doc
drwxrwxr-x    2 telorb   telorb       4096 Nov  3 17:01 dumps
drwxrwxr-x    2 telorb   telorb       4096 Nov 14 14:05 etc
drwxrwxr-x    2 telorb   telorb       4096 Nov 14 12:59 etc_20051114
-rwxrwxr-x    1 telorb   telorb      91865 Nov 14 14:05 installLog
drwxrwxr-x    2 telorb   telorb       4096 Oct 31 09:52 logd
drwxrwxr-x    3 telorb   telorb       4096 Oct 21 12:36 logs
drwxrwxr-x    2 telorb   telorb      16384 Oct 21 12:27 lost+found
drwxrwxr-x    4 telorb   telorb       4096 Oct 21 12:36 netdump
-rw-r--r--    1 telorb   telorb      16949 Nov 14 14:30 syslog
-rwxrwxr-x    1 telorb   telorb      95318 Nov 14 12:37 syslog.bak
drwxrwxr-x    3 telorb   telorb       4096 Nov 11 17:09 system
drwxrwxr-x    2 telorb   telorb       4096 Nov 14 14:04 tmp

ls -l /opt/mirror/
total 0    (Should be the same printout as for `ls -l /opt/telorb/'!!!)
*** End: Mount point test of problem ID 40.13. ***


Observed the following processor log printouts in Proc_m0_s11 (Linux)??!!:
-> Notification: Resuming.  Restart from File=15, Offset=7585.
-> Starting LoggingDBWriter tail...
Alarm: ObjectType = Filesystem, Instance = /opt/telorb/axe/applog, FaultID = 1
IRP Time value = 20051114141745
DicosIRPAlarm.convert: IRP Cause is null or non numeric, checking ProbableCause of DicosAlarm...
AckTime in IRP format = 
SnmpDIcosAlarmListener ***** Received Dicos Alarm: 
Alarm
  Alarm Type     = 4
  Object Type    = Filesystem
  Instance       = /opt/telorb/axe/applog
  Fault ID       = 1
  Severity       = 5
  Trend          = 0
  Probable cause = Mount point /opt/telorb/axe/applog is unavailable
  Time           = Mon Nov 14 15:17:45 CET 2005
  Acknowledged by= 
  ANVPairs   = 

DicosAlarmWrapper::handleAlarm() called!
Alarm: ObjectType = Filesystem, Instance = /opt/telorb/axe/applog, FaultID = 1
Alarm is found at the position 0
Alarm removed
DicosAlarmWrapper::handleAlarm() called!
Alarm: ObjectType = Filesystem, Instance = Proc_m0_s13, FaultID = 100
Alarm is found at the position 0
Alarm removed
Alarm: ObjectType = Filesystem, Instance = Proc_m0_s13, FaultID = 100
IRP Time value = 20051114141752
DicosIRPAlarm.convert: IRP Cause is null or non numeric, checking ProbableCause of DicosAlarm...
AckTime in IRP format = 
SnmpDIcosAlarmListener ***** Received Dicos Alarm: 
Alarm
  Alarm Type     = 4
  Object Type    = Filesystem
  Instance       = Proc_m0_s13
  Fault ID       = 100
  Severity       = 5
  Trend          = 0
  Probable cause = Mount point(s) unavailable
  Time           = Mon Nov 14 15:17:52 CET 2005
  Acknowledged by= 
  ANVPairs   = 
     (MountPoints,/reporterLogs/ /opt/telorb/axe/applog/ /opt/telorb/axe/mysql-data/ )

DicosAlarmWrapper::handleAlarm() called!
Alarm: ObjectType = Filesystem, Instance = Proc_m0_s11, FaultID = 100
Alarm is found at the position 0
Alarm removed
Alarm: ObjectType = Filesystem, Instance = Proc_m0_s11, FaultID = 100
IRP Time value = 20051114141803
DicosIRPAlarm.convert: IRP Cause is null or non numeric, checking ProbableCause of DicosAlarm...
AckTime in IRP format = 
SnmpDIcosAlarmListener ***** Received Dicos Alarm: 
Alarm
  Alarm Type     = 4
  Object Type    = Filesystem
  Instance       = Proc_m0_s11
  Fault ID       = 100
  Severity       = 5
  Trend          = 0
  Probable cause = Mount point(s) unavailable
  Time           = Mon Nov 14 15:18:03 CET 2005
  Acknowledged by= 
  ANVPairs   = 
     (MountPoints,/reporterLogs/ /opt/telorb/axe/applog/ )


Apply upgrade package "TSP4_to_TSP5_step2"
------------------------------------------
In TelORB Manager's "Upgrades" card, select "TSP4_to_TSP5_step2" and click
"Apply".

Upgrade started:  16.00:47
Upgrade finished: 18.07:06

The upgrade was successful, but the following was observed.

-- -- -- -- -- --

Lots of "User abortion" for capsule "PCFslave_tcap_itu".
Some "User abortion" for capsule "BEprocess_tcap_itu", "BEprocess2_tcap_itu"
and "NMMprocess_itu".

-- -- -- -- -- --

Proc_m0_s11 (Linux) got a core dump at ~18.00:
  core.t1131987599.u0.g0.eu0.eg0.n0.p2651.lmstarter.gz.172.16.0.11-1

Got other core dumps later on as well.
No designer available for troubleshooting.

-- -- -- -- -- --

Proc_m0_s17 (Dicos) reloaded at 18.51:42:

Processor: Proc_m0_s17 [1.1.9]
Port 745703666
        Port 747297652
        Port 745634726

|
--------------------------------
LOG_ERR: Deedug.cc:852 [SCC/AXG73 R1O02a] Connection lost to DUG [1003291], reason: 2002
-----> Restarting dynamic keyed process(es) in DU(s) with id=1003291
DumpDriver: NOTIFICATION: 7 Dump(s) (84 discarded)
--------------------------------
| Capsule abortion no 548
| Id: 13360402
| Name: De2SubPT
| Reason: Could not create port
LOG_ERR: KERNEL: Capsule no 13360402 (De2SubPT) aborted with reason: Could not create port
| Dump:

Program Error at 00678a6a

Register dump:

  EAX: 00000000  ECX: 00000000  EDX: 00000000  EBX: 00000000
  ESP: a000fd44  EBP: a000fd60  ESI: 00000000  EDI: 00000000

  EIP: 00678a6a  EFLAGS: 00040297

Stack dump:

  a000fd44: 1002cbfb 00000379 a000fd94 34110000 00000000 00000000 39f92bd8
  a000fd60: a000fea0 1001f7c7 00000379 a000fd94 a000fea0 1001f7a3 a000fda0
            00000100 21a05c60 a000feac a0030f50 00000000 f0020000 00000001
              ....  
            1002cbfb 00000033 a000fecc a0030f50 a0010330 10022aef a0030f50
  a000fea0: a000fef0 10028590 21a05c60 a000fecc a0030018 39a979c8 a0030018
            a0030fdc a0030fc8 a0010330 10022aef 00000000 a000ff00 a0030f50
            1002a1c0 00000000 00000070 1003078d 1001ee50 00000000
  a000fef0: a000ff20 1002ff6d a0030f50 00000001 1003078d 100308a2 a0030018
            a0030018 39a979c8 a000ff50 1003078d 00000070
  a000ff20: a000ff50 10030796 a0030f50 a0030018 a0030fdc a000ff54 a0030018
            2a3db920 2a3db920 a000ff80 111b3f38 00000024
  a000ff50: a000ff80 111b3f5c a0030018 2a3db920 00000054 a0030fdc 00000054
            00000000 00000054 a000ffb0 111b3fb2 00000004
  a000ff80: a000ffb0 111b3fbb a0030018 2a3db920 00000054 111b3fa3 39a979c8
            0065eb50 ffffffd8 ffffffe8 a003034c 00000000
  a000ffb0: a000ffd0 0065bc5b 2a3db920 00000054 00000000 00000000 00000000
            00000000
  a000ffd0: a000fff0 0065eb6b 39a979c8 0000000a 0000000a 00000001 00000005
            bbbbbbbb
  a000fff0: 00000000

Call chain: 00678a6a 1001f7c7 10028590 1002ff6d 10030796 111b3f5c 111b3fbb 0065bc5b 0065eb6b

Target i486
LM/AXG561=R4C11:.text+0009b18a
LM/AXG425=R5C12:.text+0001f7c7
LM/AXG425=R5C12:.text+00028590
LM/AXG425=R5C12:.text+0002ff6d
LM/AXG425=R5C12:.text+00030796
LM/PRO401=R2B12:.text+000002ec
LM/PRO401=R2B12:.text+0000034b
LM/AXG561=R4C11:.text+0007e37b
LM/AXG561=R4C11:.text+0008128b

Capsule 13360402 "De2SubPT"
Process 13360402 [524304] "De2SubPT"
    Thread 13403188 "" [Ready]
        00

|
--------------------------------
--------------------------------
| Capsule abortion no 549
| Id: 13361770
| Name: De2SubPT
| Reason: Could not create port
LOG_ERR: KERNEL: Capsule no 13361770 (De2SubPT) aborted with reason: Could not create port
| Dump:

Program Error at 00678a6a

Register dump:

  EAX: 00000000  ECX: 00000000  EDX: 00000000  EBX: 00000000
  ESP: a000fd44  EBP: a000fd60  ESI: 00000000  EDI: 00000000

  EIP: 00678a6a  EFLAGS: 00040297

Stack dump:

  a000fd44: 1002cbfb 00000379 a000fd94 00000010 ffffffa8 a0030e88 a0010130
  a000fd60: a000fea0 1001f7c7 00000379 a000fd94 a000fea0 1001f7a3 a000fda0
            00000100 21a05c60 a000feac a0030f50 a0030cf8 a0030cc0 00000001
              ....  
            1002cbfb 00000033 a000fecc a0030f50 a0010330 10022aef a0030f50
  a000fea0: a000fef0 10028590 21a05c60 a000fecc a0030018 3c5e06a8 a0030018
            a0030fdc a0030fc8 a0010330 10022aef 00000000 a000ff00 a0030f50
            1002a1c0 00000000 00000070 1003078d 1001ee50 bbbbbbbb
  a000fef0: a000ff20 1002ff6d a0030f50 00000001 1003078d 100308a2 a0030018
            a0030018 3c5e06a8 a000ff50 1003078d 00000070
  a000ff20: a000ff50 10030796 a0030f50 a0030018 a0030fdc a000ff54 a0030018
            29012040 29012040 a000ff80 111b3f38 00000024
  a000ff50: a000ff80 111b3f5c a0030018 29012040 00000048 a0030fdc 00000048
            2c9d25d1 00000048 a000ffb0 111b3fb2 00000004
  a000ff80: a000ffb0 111b3fbb a0030018 29012040 00000048 111b3fa3 3c5e06a8
            0065eb50 00000d63 bbbbbbbb 21a062a0 a0030018
  a000ffb0: a000ffd0 0065bc5b 29012040 00000048 00000000 000000f0 a0030e70
            a0030ea8
  a000ffd0: a000fff0 0065eb6b 3c5e06a8 a0030018 2155bc00 bbbbbbbb 00430ae1
            bbbbbbbb
  a000fff0: 00000000

Call chain: 00678a6a 1001f7c7 10028590 1002ff6d 10030796 111b3f5c 111b3fbb 0065bc5b 0065eb6b

Target i486
LM/AXG561=R4C11:.text+0009b18a
LM/AXG425=R5C12:.text+0001f7c7
LM/AXG425=R5C12:.text+00028590
LM/AXG425=R5C12:.text+0002ff6d
LM/AXG425=R5C12:.text+00030796
LM/PRO401=R2B12:.text+000002ec
LM/PRO401=R2B12:.text+0000034b
LM/AXG561=R4C11:.text+0007e37b
LM/AXG561=R4C11:.text+0008128b

Capsule 13361770 "De2SubPT"
Process 13361770 [524304] "De2SubPT"
    Thread 13403531 "" [Ready]
        00

|
--------------------------------
--------------------------------
| Capsule abortion no 550
| Id: 13361409
| Name: De2SubPT
| Reason: Could not create port
LOG_ERR: KERNEL: Capsule no 13361409 (De2SubPT) aborted with reason: Could not create port
| Dump:

Program Error at 00678a6a

Register dump:

  EAX: 00000000  ECX: 00000000  EDX: 00000000  EBX: 00000000
  ESP: a000fd44  EBP: a000fd60  ESI: 00000000  EDI: 00000000

  EIP: 00678a6a  EFLAGS: 00040297

Stack dump:

  a000fd44: 1002cbfb 00000379 a000fd94 11196820 11196600 11197060 111972f0
  a000fd60: a000fea0 1001f7c7 00000379 a000fd94 a000fea0 1001f7a3 a000fda0
            00000100 21a05c60 a000feac a0030f50 00000000 00000000 00000001
              ....

-- -- -- -- -- --

Got the following error popup window from TelORB manager:
  "Error
   Could not get system name"
  "Error
   Failed to list NFS mounts" at "Refresh" in the TM "DNS/NFS" card. This could
   be a problem which occurred already in step1 and ought to be retested!

-- -- -- -- -- --

Notifications does no longer end up in the TelORB Manager's Alarm and
Notifications panel.

-- -- -- -- -- --

  Disconnect and reconnect TM => system name OK and it was possible to
  list NFS mounts in the TM "DNS/NFS" card.

However, when connecting the TelORB Manager, the following popup window
appeared (has been seen prior to this step):
  "Error
   Could not scan Vip NetRed devices :  System Error"

Additionally, the TelORB Manager is extremely slow.

-- -- -- -- -- --

The LoadViewer disappears with the following printout:
Win.LM_MD45.R1L01.i486-Redhat-6.0: /uab/ipims_dicos/ipims_dicos20/BS2/tbAD14p10/Components_SA/Unix_SE/Unix_OB/Win_OU/src/win.cc:622: int ekmRead(SockData *): Assertion `sortindex >= 0' failed.

-- -- -- -- -- --

- Log in to one of the Linux processors and check mount info:
    telnet 172.16.0.11    (Adjust to valid IP address)
    mount
/dev/ram0 on / type ext2 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
nodev on /tmp type tmpfs (rw,mode=1777,nr_inodes=128k,nr_blocks=128k)
nodev on /usr type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
nodev on /var type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
nodev on /opt type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
io1:/opt/telorb/axe/loadingGroup01_1 on /opt/telorb/axe/loadingGroup01_1 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.0.129)
io2:/opt/telorb/axe/loadingGroup01_2 on /opt/telorb/axe/loadingGroup01_2 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.9.1)
172.16.8.129:/opt/mirror/reporterLogs on /reporterLogs type nfs (rw,soft,intr,addr=172.16.8.129)
172.16.8.129:/opt/mirror/applog on /opt/telorb/axe/applog type nfs (rw,soft,intr,addr=172.16.8.129)
172.16.1.1:/opt/mirror/reporterLogs2 on /reporterLogs2 type nfs (rw,soft,intr,addr=172.16.1.1)
172.16.8.129:/opt/mirror/mysql-data on /opt/telorb/axe/mysql-data type nfs (rw,soft,intr,addr=172.16.8.129)
    exit


Step 3 CW/OS only - IO upgrade
==============================

Preparations
------------
Fetch the ISO file from e.g.
/ipims_dicos/BS2/tbWP046/Components_SA/Unix_SE/Unix_OB/MixedIoFiles_OU/tsp45io.iso
and copy it to a CD.

(The upgrade files for steps 1 and 2 will be deleted from IO1 in this step.)

According to "TSP5 Upgrade Instruction From TSP4", 3/1531-ANA 901 04/1-1 PA3:

Prerequisites
-------------
- Perform IO backup to tape by following the instructions in
  Precondition for step 0.5 - Perform an IO backup.

- From the TelORB Manager, remove superflous backup versions, to speed up
  the upcoming rsync command. This will decrease the time spent in maintenance
  window 2.

- Get the size of the IO hard disks:
  On IO1:
    su -
    Password: rootroot
    sfdisk -s
      NSP5.0 => /dev/sda: 143566220
                total: 143566220 blocks
    exit

  On IO2:
    su -
    Password: rootroot
    sfdisk -s
      NSP5.0 => /dev/sda: 143566220
                total: 143566220 blocks
    exit

- Calculate the DRBD size:
    Calculation of DRBD size in a 1 disk system for NSP5.0:
      143566220 - (10 * 1024 * 1024) = 133080460
      133080460        # 10Gb for the OS removed
      133080460 - (128 * 1024) = 132949388
      132949388        # Leave 128Mb for the DRBD "meta data"
      132000000        # After some padding left
                       # To be used when starting the "bin/upgradeprepare"
                       # script below


Upgrade IO2 from the upgrade CD
-------------------------------

- Physically, connect a serial link to IO2, to be able to monitor it during
  the upgrade procedure.

- Physically, insert the IO upgrade CD into the CD reader of IO2.

- On IO2, mount the CD:
    su -
    Password: rootroot
    mount /mnt/cdrom

- On IO2, execute the "bin/upgradeprepare" script from the CD (use the DRBD
  size calculated for your system, i.e. adjust 132000000 below if required):
    /mnt/cdrom/bin/upgradeprepare -D 132000000 -n Proc_m1_s1,Proc_m2_s1

--- Start of example printout ---
132000000
Proc_m1_s1
Proc_m2_s1
my ioindex 0 ioindex = 1
mac = 00:20:CE:C9:93:D2tmac = 00:20:CE:C9:A0:92
mac = 00:20:CE:C9:93:D2tmac = 00:20:CE:C9:A0:93
mac = 00:20:CE:C9:93:D2tmac = 00:20:CE:C9:A0:90
my ioindex 0 ioindex = 2
mac = 00:20:CE:C9:A0:92tmac = 00:20:CE:C9:A0:92
mac = 00:20:CE:C9:A0:92tmac = 00:20:CE:C9:A0:93
mac = 00:20:CE:C9:A0:92tmac = 00:20:CE:C9:A0:90

=========================================================
# System configuration for IO upgrade

# CD device [/mnt/cdrom]
cd_device=/dev/hda

# /boot partition. The GRUB mapping must match!
boot_part=/dev/sda1,ext2
boot_part_grub=(hd0,0)

# Root and loadingGrop (drbd) devices
# If these differs we assume a 2x40GB system.
device=/dev/sda
#drbddevice=(same as root)

# Hostname, should be 'Proc_m1_s1' or 'Proc_m2_s1'
hostname=Proc_m2_s1

# Explicitly set DRBD size
drbdsize=132000000

=========================================================
Is it OK to go on with these values (NO/yes)?
yes
Preparing /boot ...
Writing system information ...
Converting the telorb.conf ...
Creating the upgradedata.tgz ...
Updating the GRUB menu ...
--- End of example printout ---

    exit

- Save the "/boot/upgradedata.tgz" file to a safe place (preferably externally):
    scp -r /boot/upgradedata.tgz io1:/boot/upgradedata.tgz
      Resulted in: "scp: /boot/upgradedata.tgz: Permission denied"
      Used the following location instead:
    scp -r /boot/upgradedata.tgz io1:/home/telorb/

- Reboot IO2:
    su root
    Password: rootroot
    reboot

--- Start: Printout example ---
  :
Unpacking root-fs archive ...
5 %
10 %
15 %
20 %
25 %
JBD: barrier-based sync failed on sda7 - disabling barriers   (!!!)
30 %
JBD: barrier-based sync failed on sda8 - disabling barriers   (!!!)
35 %
40 %
45 %
50 %
55 %
60 %
65 %
70 %
75 %
80 %
85 %
90 %
95 %
JBD: barrier-based sync failed on sda6 - disabling barriers   (!!!)
100 % ( 58300 )
Install TSP4/5 Hybrid IO files ...
Syncing disks ...
Unmounting file-systems ...
Setup Grub ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
JBD: barrier-based sync failed on sda6 - disabling barriers   (!!!)
Probing devices to guess BIOS drives. This may take a long time.
DRBD and mirror setup ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
drbd: initialised. Version: 0.7.10 (api:77/proto:74)
drbd: SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
drbd: registered as block device major 147
drbd0: Creating state block
drbd0: resync bitmap: bits=33000000 words=1031250
drbd0: size = 125 GB (132000000 KB)
drbd0: Assuming that all blocks are out of sync (aka FullSync)
drbd0: 132000000 KB now marked out-of-sync by on disk bit-map.
drbd0: drbdsetup [1292]: cstate Unconfigured --> StandAlone
drbd0: Secondary/Unknown --> Primary/Unknown
    /dev/drbd0 ...
JBD: barrier-based sync failed on sda7 - disabling barriers   (!!!)
Copy the sitedb and other stuff to the mirror ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on drbd0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Prepare for upgrade of the second IO ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
  :
--- End: Printout example ---

After the upgrade has finished, IO2 will be rebooted again, automatically.
After the second reboot, you will get a login prompt on the serial console.

IO2 has now been upgraded to a Hybrid TSP4/TSP5 IO.

- Log in to IO2 as telorb user (not from serial console) and check its status:
    ssh -X telorb@toXXio2  (Adjust toXX to valid TSP system)
    Password: telorb       (Observe that the password has been changed!)
    cat /proc/drbd

--- Start: Printout example ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:WFConnection st:Primary/Unknown ld:Consistent
    ns:0 nr:0 dw:7012 dr:390 al:21 bm:275 lo:0 pe:0 ua:0 ap:0
 1: cs:Unconfigured
--- End: Printout example ---

- The alarm "Mount point /loadingGroup01_2 is unavailable" should be present in
  the alarm log.

- Since the contents of IO2's loadingGroup is almost empty, it has to
  be copied from IO1 by using the rsync command:
  On IO2:
    ls -l /opt/mirror/loadingGroup01_1/ (Check before)
      --- Start printout ---
        total 8
        drwxr-xr-x  3 telorb telorb 4096 Oct 10 13:30 PXE_X86PC
        drwxr-xr-x  4 telorb telorb 4096 Oct 10 13:33 tspdeviceboard
      --- End printout ---
    rsync -a --update -v telorb@io1:/opt/telorb/axe/loadingGroup01_1 /opt/mirror
    Password: tel123orb
    ls -l /opt/mirror/loadingGroup01_1/ (Check after)
    Verify that the directories PXE_X86PC and tspdeviceboard are kept among
    the copied directories and files.
    ls -l /opt/mirror/loadingGroup01_2/ (Should show the same as above)

- Physically, remove the CD.

- Perform re-mount towards IO2:
    All traffic processors (TPs) must be ordered to re-mount towards IO2.
    This is achieved in different ways depending on if Dicos OS or Linux OS
    is executing on the TP.

    In the TelORB Manager's "DNS/NFS" card, "File System Configuration"
    area, click "Refresh".
      "loadingGroup01_2" should be red-marked.

    To re-mount all Dicos processors, perform the umount and mount commands as
    follows:
      In the TelORB Manager's "DNS/NFS" card, "File System Command"
      input field, enter the following (verify the IP addresses before using
      the mount command below):
      umount /loadingGroup01_2 followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.
        -and-
      mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.1.1 -o ipaddr=172.16.9.1 /dev/rpc2 /loadingGroup01_2/ /opt/mirror/loadingGroup01_2 followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.

      Click Refresh to verify the mountings.
      "nfs  /loadingGroup01_1...", "nfs  /loadingGroup01_2..." and
      "nfs  /upgradePackages..." should be green-marked.

    To re-mount all Linux processors (excluding IOs and FSs), perform disable
    and enable (reload) of each processor as described below:
    In the TelORB Manager's "Processors" card, disable and enable all Linux
    processors, one by one.

    Verify that the re-mounting of one of the Linux processors was successful:
      From any IO:
        telnet 172.16.0.11  (Adjust Proc_m0_s11 to valid Linux processor)
        login: telorb
        mount
          --- Start of example printout ---
          /dev/ram0 on / type ext2 (rw)
          none on /proc type proc (rw)
          none on /dev/pts type devpts (rw,gid=5,mode=620)
          nodev on /tmp type tmpfs (rw,mode=1777,nr_inodes=128k,nr_blocks=128k)
          nodev on /usr type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
          nodev on /var type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
          nodev on /opt type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
          io1:/opt/mirror/loadingGroup01_1 on /opt/telorb/axe/loadingGroup01_1 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.0.129)
          io2:/opt/mirror/loadingGroup01_2 on /opt/telorb/axe/loadingGroup01_2 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.1.1)
          --- End of example printout ---

        exit


Upgrade IO1
-----------
- Physically, connect a serial link to IO1, to be able to monitor it during
  the upgrade procedure.

- Perform the following commands on IO1:
    ssh -X telorb@toXXio1  (Adjust toXX to valid TSP system)
    Password: tel123orb
    su root
    Password: rootroot
    scp io2:/boot/upgradedata.tgz /tmp
    Password: rootroot
    cd /boot
    tar xvzf /tmp/upgradedata.tgz
    /boot/upgradedata/upgradeprepare2

--- Start: Example printout ---
=========================================================
Address to the *other* IO on subnet0: 172.16.1.1
Local address on subnet0: 172.16.0.129/255.255.248.0 (00:20:CE:C9:93:D2)
My io-index: 1
Boot-partition: /dev/sda1,ext2 (hd0,0)
Root/loadingGroup devices: /dev/sda, /dev/sda
External interface data: 00:20:CE:C9:93:D0=134.138.187.54/255.255.248.0,
DRBD device size: 132000000
=========================================================
Is it OK to go on with these values (NO/yes)?
yes

DONE!
--- End: Example printout ---

    reboot  (Reboot IO1)

    IO1 will be booted from RAM-disk and then IO1 will be upgraded.
    After the upgrade has finished, IO1 will be rebooted again, automatically.
    "Starting HybridIoSwGuard WARNING: /boot not exported", received on serial
    console. OK??!!

    One of the printouts before rebooting again:
      "TSP4/5 Hybrid installation finished, rebooting ..."

    After the second reboot, you will get a login prompt on the serial console.

- Log in to IO1 as telorb user (not from serial console) and verify that IO1 has
  become secondary IO:
    ssh -X telorb@toXXio1  (Adjust toXX to valid TSP system)
    Password: telorb       (Observe that the password has been changed!)
    cat /proc/drbd

--- Start: Printout example ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
    ns:0 nr:846496 dw:846496 dr:0 al:0 bm:178 lo:0 pe:0 ua:0 ap:0
        [>...................] sync'ed:  0.7% (128081/128906)M
        finish: 4:20:13 speed: 8,156 (4,940) K/sec
--- End: Printout example ---

    Wait for IO1 to synchronize from IO2. Check the progress either
    from IO1 or IO2:
      cat /proc/drbd

- Only valid for NSP 5.0: If the system is an NSP 5.0 system, hardware wise,
    it is possible to speed up the DRBD synching via the Gigabit link,
    which is connected between the IO processors (en-1, eth3).
      To accomplish this, perform the following:

      Make sure the Gigabit link between IO1 (eth3) and IO2 (eth3) is physically
      connected, and then verify that it is configured as follows:
        On IO:
          /sbin/ifconfig -a  (Verify that inet addr for eth3 is configured)

        If not configured (info from uabnick) (not yet tested):
        From IO1:
          ifconfig eth3 down
          ifconfig eth3 192.11.0.1 netmask 255.255.255.0 up

        From IO2:
          ifconfig eth3 down
          ifconfig eth3 192.11.0.2 netmask 255.255.255.0 up

      Speed up the sync rate from IO2 (primary IO):
      o Verify that IO2 is primary (which it should be):
          su -
          Password: rootroot
          drbdsetup /dev/drbd0 state
          If the output is "Primary/Secondary", IO2 is primary.
      o Show the sync rate "Syncer options: rate" (among other things):
          drbdsetup /dev/drbd0 show
      o Set the synchronization speed to 30MBytes/second (default value: 8M)
          drbdsetup /dev/drbd0 syncer -r 30M
      o Show the sync rate:
          drbdsetup /dev/drbd0 show
      o Wait until the synchronization is finished.
        You can monitor the synchronization by entering the following command
        repeatedly:
          cat /proc/drbd

      o When the sychronization is finished, restore the synchronization speed
        back to the default value 8MBytes/second:
          drbdsetup /dev/drbd0 syncer -r 8M
        DO NOT FORGET TO RESTORE!!!
      o Show the sync rate:
          drbdsetup /dev/drbd0 show
      o Leave su mode:
          exit

      During the synchronization, the cat command will result in
      something like the following:
--- Start printout from IO1 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
    ns:0 nr:708124 dw:708124 dr:0 al:0 bm:170 lo:0 pe:0 ua:0 ap:0
        [>...................] sync'ed:  0.6% (128215/128906)M
        finish: 7:00:48 speed: 5,164 (4,944) K/sec
--- End printout from IO1 ---

--- Start printout from IO2 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:1345772 nr:0 dw:308072 dr:1345238 al:143 bm:476 lo:0 pe:0 ua:0 ap:0
        [>...................] sync'ed:  1.1% (127592/128906)M
        finish: 6:12:52 speed: 5,824 (4,872) K/sec
 1: cs:Unconfigured
--- End printout from IO2 ---

      When the synchronization is ready, the cat command will result in
      something like the following:
--- Start printout from IO1 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:Connected st:Secondary/Primary ld:Consistent
    ns:0 nr:132193144 dw:132193144 dr:0 al:0 bm:8184 lo:0 pe:0 ua:0 ap:0
--- End printout from IO1 ---

--- Start printout from IO2 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:Connected st:Primary/Secondary ld:Consistent
    ns:132193148 nr:0 dw:500560 dr:132000126 al:143 bm:8451 lo:0 pe:0 ua:0 ap:0
 1: cs:Unconfigured
--- End printout from IO2 ---

Note: It is of the utmost importance not to proceed with these instructions
      until the synchronization of IO1 has finished!

- The processor consoles have been closed, so new ones should be opened from
  IO1:
    STS_console --font 6x10 --max 99

    Not possible to open STS_console with the command parameters above!
    "Uncaught exception from user code:
        No config file found! at /opt/telorb/bin/STS_console line 129."??!!

* The following printouts start appearing in all Dicos processor logs, and they
  keep on coming on a regular basis:
      :
    nmbOfTestedIpAddrM = 2
    nmbOfTestedIpAddrM = 2
    nmbOfTestedIpAddrM = 2
    nmbOfTestedIpAddrM = 2
      :
  Is this OK or not??!! (RPC driver=OU/D96)

- Physically, connect a serial link to IO2, to be able to monitor it during
  the upcoming reboot, in case anything goes wrong.

- Reboot IO2 (to get IO1 to become primary for the mountings further down
  to take effect):
    su root
    Password: rootroot
    reboot

Note: loadingGroup01_1 will not be available from now on until it is mounted
      in the next step. Additionally, loadingGroup01_2 will not be available,
      since IO2 is secondary.
      Is this OK??!!

    After the reboot, you will get a login prompt on the serial console.

- Log in to IO2 as telorb user (not from serial console) to verify that it is
  up and running:
    ssh -X telorb@toXXio2  (Adjust toXX to valid TSP system)
    Password: telorb
    cat /proc/drbd
      Should be "Secondary/Primary".

- On IO1, verify that IO1 has become primary IO (can be seen in the previous
  command, but anyway):
    cat /proc/drbd
      Should be "Primary/Secondary".

- At this stage, no mount points are available, which is indicated by alarms.

- Perform re-mount towards IO1:
    All traffic processors (TPs) must be ordered to re-mount towards IO1.
    This is achieved in different ways depending on if Dicos OS or Linux OS
    is executing on the TPs.

    In the TelORB Manager's "DNS/NFS" card, "File System Configuration"
    area, click "Refresh".
      "loadingGroup01_1", "loadingGroup01_2" and "upgradePackages" should be
      red-marked.

    To re-mount all Dicos processors, perform the umount and mount commands as
    follows:
      In the TelORB Manager's "DNS/NFS" card, "File System Command"
      input field, enter the following (verify the IP addresses before using
      the mount commands below):
      umount /loadingGroup01_1 followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.
        -and-
      mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc1 /loadingGroup01_1/ /opt/mirror/loadingGroup01_1 followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.

      umount /upgradePackages followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.
        -and-
      mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/mirror/upgradePackages followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.

      Error result printout:
        "Operation failed for 1 processors with errno 11."
        Why??!!
        On Proc_m1_s9:
        "DEBUG INFO: "umount /upgradePackages" done
         nmbOfTestedIpAddrM = 2
         LOG_ERR: DswomAvailabilityFSAgent.cc:132 [OU/D142 R1A34] Couldn't create the file loadingGroup01_2/Outage/TimeStamp
LOG_ERR: DfsAgentSystem.cc:57 [OU/D88 R1A28m] "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/mirror/upgradePackages" failed; error-code = 11 (Device or resource busy)"
        Performed an umount and mount of upgradePackages a second time and this
        time it worked.

      Verify the mountings with "Refresh".
      "/loadingGroup01_1" and "/upgradePackages" should be green-marked, whereas
      "/loadingGroup01_2" should be red-marked.

    Should "/loadingGroup01_2" be un-mounted from the "DNS/NFS" card, since it
    is no longer used??!!

    To re-mount all Linux processors (excluding IOs and FSs), perform disable
    and enable (reload) of each processor as described below:
    In the TelORB Manager's "Processors" card, disable and enable all Linux
    processors, one by one.

- If required (for SS7), copy the TSP 5 Runtime Environment to IO1.

From a CW/OS point of view, step 3 is now completed.

(Should the GESB/SCB loadable software (firmware) be upgraded??!!
 No! Nothing has been changed!)


Step 3 CW/OS, NM & SS7 - IO upgrade
===================================

Preparations
------------
Fetch the ISO file from e.g.
/ipims_dicos/BS2/tbWP046/Components_SA/Unix_SE/Unix_OB/MixedIoFiles_OU/tsp45io.iso
and copy it to a CD.

(The upgrade files for steps 1 and 2 will be deleted from IO1 in this step.)

According to "TSP5 Upgrade Instruction From TSP4", 3/1531-ANA 901 04/1-1 PA5.9:

Prerequisites
-------------
- Perform IO backup to tape by following the instructions in
  Precondition for step 0.5 - Perform an IO backup.

- From the TelORB Manager, remove superflous backup versions, to speed up
  the upcoming rsync command. This will decrease the time spent in maintenance
  window 2.

- SS7 step:
  Save the DCM file located on IO1:
    On e.g. WS:
      cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/step3
      Rename existing file, if any, e.g.
      mv 2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW.dcm 2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW.dcm.051115
      Copy file:
      scp telorb@to14io1:/opt/DCM/2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW_to14.dcm .
      (scp telorb@to14io1:/opt/DCM/2BE_2FE_2Linkset_16Links_ITU_TCAP_ITU_NW.dcm .)

- NM step:
  Redirect NM storage from IO2 to IO1:
    On IO1:
      cd /tmp/NM_Upgrade_step123/scripts

    On tos2:
      cd /home/dicostest/tosFiles/to14/upgradepath/step2
      scp TSP4_to_TSP5_step2.config telorb@to14io1:/opt/telorb/axe/.

    On IO1:
      ./redirectPmfToIo1Only /opt/telorb/axe/TSP4_to_TSP5_step2.config

--- Start printout from IO1 ---
--------------------------------------------
--- INPUT FILE SPECIFIC SETTINGS
--------------------------------------------
loadingGroup "*.config" file: /opt/telorb/axe/TSP4_to_TSP5_step2.config
Node "telorb.conf" file:      /opt/telorb/etc/telorb.conf
Undo activated:               0
Mounting activated:           0
  
--------------------------------------------
--- IO1 ADDRESS
--------------------------------------------
IO1_1:                        172.16.0.129
IO1_2:                        172.16.8.129
--------------------------------------------
--- IO2 ADDRESS
--------------------------------------------
IO2_1:                        172.16.1.1
IO2_2:                        172.16.9.1

Shall I continue with the above settings (NO/yes)? yes

Continuing with the "redirectPmfToIO1Only" script execution...
Setting environment variable on Dicos TP: Proc_m0_s9 <172.16.0.9:8002>
PMF_IOREDUNDANCY_ENABLED = false
Executing: setenv PMF_IOREDUNDANCY_ENABLED false
[ DONE ]
--- End printout from IO1 ---

- NM step:
  Verify the redirected NM storage from IO2 to IO1:
    On IO1:
      telnet 172.16.0.9 8002
      cd /env
      printenv

        Printout:
          ...
          PMF_IOREDUNDANCY_ENABLED = false
          ...

     quit

- Get the size of the IO hard disks:
  On IO1:
    su -
    Password: rootroot
    sfdisk -s
      NSP5.0 => /dev/sda: 143566220
                total: 143566220 blocks
    exit

  On IO2:
    su -
    Password: rootroot
    sfdisk -s
      NSP5.0 => /dev/sda: 143566220
                total: 143566220 blocks
    exit

- Calculate the DRBD size:
    Calculation of DRBD size in a 1 disk system for NSP5.0:
      143566220 - (10 * 1024 * 1024) = 133080460
      133080460        # 10Gb for the OS removed
      133080460 - (128 * 1024) = 132949388
      132949388        # Leave 128Mb for the DRBD "meta data"
      132000000        # After some padding left
                       # To be used when starting the "bin/upgradeprepare"
                       # script below


Upgrade IO2 from the upgrade CD
-------------------------------

- Physically, connect a serial link to IO2, to be able to monitor it during
  the upgrade procedure, in case anything goes wrong.

- Physically, insert the IO upgrade CD into the CD reader of IO2.

- On IO2, mount the CD:
    su -
    Password: rootroot
    mount /mnt/cdrom

- On IO2, execute the "bin/upgradeprepare" script from the CD (use the DRBD
  size calculated for your system, i.e. adjust 132000000 below if required):
    /mnt/cdrom/bin/upgradeprepare -D 132000000 -n Proc_m1_s1,Proc_m2_s1

--- Start of example printout ---
132000000
Proc_m1_s1
Proc_m2_s1
my ioindex 0 ioindex = 1
mac = 00:20:CE:C9:93:D2tmac = 00:20:CE:C9:A0:92
mac = 00:20:CE:C9:93:D2tmac = 00:20:CE:C9:A0:93
mac = 00:20:CE:C9:93:D2tmac = 00:20:CE:C9:A0:90
my ioindex 0 ioindex = 2
mac = 00:20:CE:C9:A0:92tmac = 00:20:CE:C9:A0:92
mac = 00:20:CE:C9:A0:92tmac = 00:20:CE:C9:A0:93
mac = 00:20:CE:C9:A0:92tmac = 00:20:CE:C9:A0:90

Specify external DNS-servers. If no external DNS-servers should be used, leave the field empty.
Otherwise enter the IP-address(es) of the external DNS-servers, separated by space.
DNS servers: 134.138.201.17 134.138.226.13

=========================================================
# System configuration for IO upgrade

# CD device [/mnt/cdrom]
cd_device=/dev/hda

# /boot partition. The GRUB mapping must match!
boot_part=/dev/sda1,ext2
boot_part_grub=(hd0,0)

# Root and loadingGrop (drbd) devices
# If these differs we assume a 2x40GB system.
device=/dev/sda
#drbddevice=(same as root)

# Hostname, should be 'Proc_m1_s1' or 'Proc_m2_s1'
hostname=Proc_m2_s1

# DNS servers
dns_servers=134.138.201.17,134.138.226.13

# Explicitly set DRBD size
drbdsize=132000000

=========================================================
Is it OK to go on with these values (NO/yes)?
yes
Preparing /boot ...
Writing system information ...
Converting the telorb.conf ...
Creating the upgradedata.tgz ...
Updating the GRUB menu ...
--- End of example printout ---

    exit

- Save the "/boot/upgradedata.tgz" file to a safe place (preferably
  externally):
    On IO1:
      su
      Password: rootroot
      scp -r io2:/boot/upgradedata.tgz /boot/upgradedata_io2.tgz
        Resulted in: "root@io2's password: Permission denied, please try again."
      exit

      Used the following location instead as telorb user on IO2:
      scp -r /boot/upgradedata.tgz io1:/home/telorb/.
      Also save it externally:
      scp -r /boot/upgradedata.tgz uabmsu@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/.

- Reboot IO2:
    su root
    Password: rootroot
    reboot

--- Start: Printout example ---
  :
Unpacking root-fs archive ...
5 %
10 %
15 %
20 %
25 %
JBD: barrier-based sync failed on sda7 - disabling barriers   (!!!)
30 %
JBD: barrier-based sync failed on sda8 - disabling barriers   (!!!)
35 %
40 %
45 %
50 %
55 %
60 %
65 %
70 %
75 %
80 %
85 %
90 %
95 %
JBD: barrier-based sync failed on sda6 - disabling barriers   (!!!)
100 % ( 58300 )
Install TSP4/5 Hybrid IO files ...
Syncing disks ...
Unmounting file-systems ...
Setup Grub ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
JBD: barrier-based sync failed on sda6 - disabling barriers   (!!!)
Probing devices to guess BIOS drives. This may take a long time.
DRBD and mirror setup ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
drbd: initialised. Version: 0.7.10 (api:77/proto:74)
drbd: SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
drbd: registered as block device major 147
drbd0: Creating state block
drbd0: resync bitmap: bits=33000000 words=1031250
drbd0: size = 125 GB (132000000 KB)
drbd0: Assuming that all blocks are out of sync (aka FullSync)
drbd0: 132000000 KB now marked out-of-sync by on disk bit-map.
drbd0: drbdsetup [1292]: cstate Unconfigured --> StandAlone
drbd0: Secondary/Unknown --> Primary/Unknown
    /dev/drbd0 ...
JBD: barrier-based sync failed on sda7 - disabling barriers   (!!!)
Copy the sitedb and other stuff to the mirror ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on drbd0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Prepare for upgrade of the second IO ...
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
  :
--- End: Printout example ---

After the upgrade has finished, IO2 will be rebooted again, automatically.
After the second reboot, you will get a login prompt on the serial console.

IO2 has now been upgraded to a Hybrid TSP4/TSP5 IO.

- Log in to IO2 as telorb user (not from serial console) and check its status:
    ssh -X telorb@toXXio2  (Adjust toXX to valid TSP system)
    Password: telorb       (Observe that the password has been changed!)
    cat /proc/drbd

    --- Start: Printout example ---
      version: 0.7.10 (api:77/proto:74)
      SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
       0: cs:WFConnection st:Primary/Unknown ld:Consistent
          ns:0 nr:0 dw:43532 dr:414 al:29 bm:283 lo:0 pe:0 ua:0 ap:0
       1: cs:Unconfigured
    --- End: Printout example ---

- The alarms "Mount point /loadingGroup01_2 is unavailable" and "Mount point
  /reporterLogs2 is unavailable" should be present in the alarm log.
  Additionally, the alarm "Mount point(s) unavailable" for /reporterLogs2
  for all Linux processors should also be present in the alarm log.

- Since the contents of IO2's loadingGroup is almost empty, it has to
  be copied from IO1 by using the rsync command:
  On IO2:
    ls -l /opt/mirror/loadingGroup01_1/ (Check before)
      --- Start printout ---
        total 8
        drwxr-xr-x  3 telorb telorb 4096 Nov 15 16:18 PXE_X86PC
        drwxr-xr-x  4 telorb telorb 4096 Nov 15 16:21 tspdeviceboard
      --- End printout ---
    rsync -a --update -v telorb@io1:/opt/telorb/axe/loadingGroup01_1 /opt/mirror
    Password: tel123orb
    ls -l /opt/mirror/loadingGroup01_1/ (Check after)
    Verify that the directories PXE_X86PC and tspdeviceboard are kept among
    the copied directories and files.
    ls -l /opt/mirror/loadingGroup01_2/ (Should show the same as above)

- Physically, remove the CD.

- Perform re-mount towards IO2:
    All traffic processors (TPs) must be ordered to re-mount towards IO2.
    This is achieved in different ways depending on if Dicos OS or Linux OS
    is executing on the TP.

    In the TelORB Manager's "DNS/NFS" card, "File System Configuration"
    area, click "Refresh".
      "/loadingGroup01_2" and "/reporterLogs2" should be red-marked.

    To re-mount all Dicos processors, execute the following script on IO1:
      cd /opt/telorb/axe/scripts
        If the remount2IO.exp script does not exist in this directory, you will
        have to fetch it from "ftp://rftp.uab.ericsson.se/pub/SysVer/UpgTSP4_5/"
        via a web browser (right click on the remount2IO.exp link and save to
        (Save Link As...) e.g. your WS at e.g.
        /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff/
        and thereafter copy it to IO2
        mkdir scripts, cd scripts,
        scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453/SIV_stuff/remount2IO.exp .
        chmod +x remount2IO.exp)
      ./remount2IO.exp 172.16.0.9 8002 2 172.16.1.1 172.16.9.1
             (172.16.0.9 = IP address of 1st Dicos loader processor,
              8002 = port to access 1st Dicos loader processor,
              2 = IO2,
              172.16.1.1 = IP address for subnet A for IO,
              172.16.9.1 = IP address for subnet B for IO)

      (An alternative way to re-mount all Dicos processors is to perform the
      umount and mount commands as follows (only CW/OS considered below):
        In the TelORB Manager's "DNS/NFS" card, "File System Command"
        input field, enter the following (verify the IP addresses before
        using the mount command below):
        umount /loadingGroup01_2 followed by Enter/Return.
        Wait for the result popup window "Operation succeeded." Click "OK".
          -and-
        mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.1.1 -o ipaddr=172.16.9.1 /dev/rpc2 /loadingGroup01_2/ /opt/mirror/loadingGroup01_2
        followed by Enter/Return.
        Wait for the result popup window "Operation succeeded." Click "OK".

        Also consider Dicos processor re-mounting for NM mount points.

        Click Refresh to verify the mountings.
        "nfs  /loadingGroup01_1...", "nfs  /loadingGroup01_2..." and
        "nfs  /upgradePackages..." should be green-marked. +NM)

      Note: "/reporterLogs2" should not be mounted. It will be unmounted
            (removed) when executing the "moveNmDataFromIo1ToIo2" script
            later on.

    Also consider Dicos processor re-mounting for any application mountings.

    Verify the Dicos processor re-mounting, by clicking Refresh in the
    TelORB Manager's "DNS/NFS" card, "File System Configuration" area.
        "nfs  /loadingGroup01_1...", "nfs  /loadingGroup01_2..." and
        "nfs  /upgradePackages..." should be green-marked as well as the
        rest of the mountings. "/reporterLogs2" will be red-marked.

    To re-mount all Linux processors (excluding IOs and FSs), perform disable
    and enable (reload) of each processor as described below:
    In the TelORB Manager's "Processors" card, disable and enable all Linux
    processors, one by one.
      This resulted in a Capsule Abortion for Proc_m0_s11 (Linux):
        core.t1132135418.u0.g0.eu0.eg0.n0.p2382.lmstarter.gz.172.16.8.11-1
      100% load in Proc_m0_s11.
      Proc_m0_s11 reloaded spontaneously.

      No designer available for troubleshooting.

      Observation: The crashcollector files only ended up on IO2, not on IO1??!!

    If a Linux processor does not reload, it would be a good test to manually
    reload a Linux processor at this stage or at a later stage during step 3,
    to verify that the processor does not get 100% load and if it continues
    reloading spontaneously.

    Verify that the re-mounting of one of the Linux processors was successful:
      From any IO:
        telnet 172.16.0.11  (Adjust Proc_m0_s11 to valid Linux processor)
        (login: telorb)
        mount
          --- Start of example printout ---
          /dev/ram0 on / type ext2 (rw)
          none on /proc type proc (rw)
          /none on /dev/pts type devpts (rw,gid=5,mode=620)
          /nodev on /tmp type tmpfs (rw,mode=1777,nr_inodes=128k,nr_blocks=128k)
          /nodev on /usr type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
          /nodev on /var type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
          /nodev on /opt type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
          /io1:/opt/mirror/loadingGroup01_1 on /opt/telorb/axe/loadingGroup01_1 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.0.129)
          /io2:/opt/mirror/loadingGroup01_2 on /opt/telorb/axe/loadingGroup01_2 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.1.1)
          /172.16.8.129:/opt/mirror/reporterLogs on /reporterLogs type nfs (rw,soft,intr,addr=172.16.8.129)
          /172.16.8.129:/opt/mirror/applog on /opt/telorb/axe/applog type nfs (rw,soft,intr,addr=172.16.8.129)
          /172.16.8.129:/opt/mirror/mysql-data on /opt/telorb/axe/mysql-data type nfs (rw,soft,intr,addr=172.16.8.129)
          --- End of example printout ---

      Note: /reporterLogs2 should not be mounted. It will be unmounted (removed)
            when executing the "moveNmDataFromIo1ToIo2" script later on.

        exit


Transfer NM data from IO1 to IO2. NM step:

- On IO2 (as telorb user), generate private and public key pairs on IO2:
    /usr/bin/ssh-keygen -b 1024 -t dsa

      --- Start: Printout ---
      Generating public/private dsa key pair.
      Enter file in which to save the key (/home/telorb/.ssh/id_dsa): 
                                                                  Press "Enter".
      Enter passphrase (empty for no passphrase): 
                                                                  Press "Enter".
      Enter same passphrase again: 
                                                                  Press "Enter".
      Your identification has been saved in /home/telorb/.ssh/id_dsa.
      Your public key has been saved in /home/telorb/.ssh/id_dsa.pub.
      The key fingerprint is:
      5d:77:3c:73:b8:d7:34:8a:c0:06:32:66:04:0a:26:b9 telorb@Proc_m2_s1
      --- End: Printout ---

- From IO1, copy telorb's public key to IO2:
      /usr/bin/scp /home/telorb/.ssh/id_dsa.pub io2:/home/telorb/.ssh/authorized_keys2
      Password: telorb

- From IO2, copy telorb's public key to IO1:
      /usr/bin/scp /home/telorb/.ssh/id_dsa.pub io1:/home/telorb/.ssh/authorized_keys2
      Password: tel123orb

  - Verify that you can enter each IO, respectively, without having to enter
    the password after the ssh command:
      From IO2:
        ssh io1
        ssh io2
        exit
        exit

- On IO1, execute the "moveNmDataFromIo1ToIo2" script:
    cd /tmp/NM_Upgrade_step123/scripts
    ./moveNmDataFromIo1ToIo2 -m

      --- Start: Example printout ---
--------------------------------------------
--- INPUT FILE SPECIFIC SETTINGS
--------------------------------------------
loadingGroup "*.config" file: /opt/telorb/axe/TSP4_to_TSP5_step2.config
Node "telorb.conf" file:      /opt/telorb/etc/telorb.conf
Undo activated:               0
Mounting activated:           1
  
--------------------------------------------
--- IO1 ADDRESS
--------------------------------------------
IO1_1:                        172.16.0.129
IO1_2:                        172.16.8.129
--------------------------------------------
--- IO2 ADDRESS
--------------------------------------------
IO2_1:                        172.16.1.1
IO2_2:                        172.16.9.1

Shall I continue with the above settings (NO/yes)? yes

Continuing with the "moveNmDataFromIo1ToIo2" script execution...
Scanning UnixCommonPool...
Scanning DicosCommonPool...
Scanning MysqlLinuxPool...

Disabling mysql daemon on Linux TP: Proc_m0_s11 <172.16.0.11>
Executing: "mv /etc/init.d/mysql /etc/init.d/mysql.bak" on host: 172.16.0.11
[ DONE ]
Disabling mysql daemon on Linux TP: Proc_m0_s13 <172.16.0.13>
Executing: "mv /etc/init.d/mysql /etc/init.d/mysql.bak" on host: 172.16.0.13
[ DONE ]

Search for running sql server...
Stopping sql server on Linux TP: Proc_m0_s11 <172.16.0.11>
Executing: "/etc/init.d/mysql.bak stop" on host: 172.16.0.11
[ DONE ]

Copy SQL data directory...
Compressing "/opt/telorb/axe/mysql-data" directory...
Copy files to "172.16.1.1:/opt/mirror/tsp/NM/Logging" & uncompress...
The authenticity of host '172.16.1.1 (172.16.1.1)' can't be established.
RSA key fingerprint is a9:e3:f9:00:d1:20:b4:25:b0:6f:9d:50:b9:8d:8b:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.1.1' (RSA) to the list of known hosts.
mydb.tar.bz2         100% |***************************************************************| 59658       00:00    
[ DONE ]

Remount SQL on Linux TP: Proc_m0_s11 <172.16.0.11>
Executing: "umount /opt/telorb/axe/mysql-data  && mount -t nfs -o soft -o intr 172.16.1.1:/opt/mirror/tsp/NM/Logging/mysql-data /opt/telorb/axe/mysql-data" on host: 172.16.0.11
[ DONE ]
Remount SQL on Linux TP: Proc_m0_s13 <172.16.0.13>
Executing: "umount /opt/telorb/axe/mysql-data  && mount -t nfs -o soft -o intr 172.16.1.1:/opt/mirror/tsp/NM/Logging/mysql-data /opt/telorb/axe/mysql-data" on host: 172.16.0.13
[ DONE ]
Remount SQL on all Dicos TP through: Proc_m0_s9 <172.16.0.9:8002>
Executing: "umount /opt/telorb/axe/mysql-data/" on host: 172.16.0.9
Executing: "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.1.1 -o ipaddr=172.16.9.1 /dev/rpc9 /opt/telorb/axe/mysql-data/ /opt/mirror/tsp/NM/Logging/mysql-data" on host: 172.16.0.9
[ DONE ]

Enable mysql daemon on Linux TP: Proc_m0_s11 <172.16.0.11>
Executing: "mv /etc/init.d/mysql.bak /etc/init.d/mysql" on host: 172.16.0.11
[ DONE ]
Enable mysql daemon on Linux TP: Proc_m0_s13 <172.16.0.13>
Executing: "mv /etc/init.d/mysql.bak /etc/init.d/mysql" on host: 172.16.0.13
[ DONE ]

Copy PMF data directory...
Compressing "/opt/telorb/axe/reporterLogs" directory...
Copy files to "172.16.1.1:/opt/mirror/tsp/NM/PMF" & uncompress...
rplogs.tar.bz2       100% |***************************************************************|  1582 KB    00:00    
[ DONE ]

Unmount PMF2 on Linux TP: Proc_m0_s11 <172.16.0.11>
Executing: "umount /reporterLogs2" on host: 172.16.0.11
[ FAILED ]
Remount PMF on Linux TP: Proc_m0_s11 <172.16.0.11>
Executing: "umount /reporterLogs && mount -t nfs -o soft -o intr 172.16.1.1:/opt/mirror/tsp/NM/PMF/reporterLogs /reporterLogs" on host: 172.16.0.11
[ DONE ]
Unmount PMF2 on Linux TP: Proc_m0_s13 <172.16.0.13>
Executing: "umount /reporterLogs2" on host: 172.16.0.13
[ FAILED ]
Remount PMF on Linux TP: Proc_m0_s13 <172.16.0.13>
Executing: "umount /reporterLogs && mount -t nfs -o soft -o intr 172.16.1.1:/opt/mirror/tsp/NM/PMF/reporterLogs /reporterLogs" on host: 172.16.0.13
[ DONE ]
Unmount PMF2 on all Dicos TP through: Proc_m0_s9 <172.16.0.9:8002>
Executing: "umount /reporterLogs2" on host: 172.16.0.9
[ DONE ]
Remount PMF on all Dicos TP through: Proc_m0_s9 <172.16.0.9:8002>
Executing: "umount /reporterLogs/" on host: 172.16.0.9
Executing: "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.1.1 -o ipaddr=172.16.9.1 /dev/rpc6 /reporterLogs/ /opt/mirror/tsp/NM/PMF/reporterLogs" on host: 172.16.0.9
[ DONE ]
Copy Applog data directory...
Compressing "/opt/telorb/axe/loadingGroup01_1/mirrored/applogConfig" directory...
Copy files to "172.16.1.1:/opt/mirror/applog" & uncompress...
applogcfg.tar.bz2    100% |***************************************************************|  2895       00:00    
Compressing "/opt/telorb/axe/applog" directory...
Copy files to "172.16.1.1:/opt/mirror/tsp/applog" & uncompress...
applog.tar.bz2       100% |***************************************************************| 16048       00:00    
[ DONE ]
      --- End: Example printout ---


The PMF and mysql data are now present on IO2.


Upgrade IO1
-----------
- Physically, connect a serial link to IO1, to be able to monitor it
  during the upgrade procedure, in case anything goes wrong.

- Perform the following commands on IO1:
    ssh -X telorb@toXXio1  (Adjust toXX to valid TSP system)
    Password: tel123orb
    su root
    Password: rootroot
    scp io2:/boot/upgradedata.tgz /tmp
    Password: rootroot
    cd /boot
    tar xvzf /tmp/upgradedata.tgz
    /boot/upgradedata/upgradeprepare2

--- Start: Example printout ---
=========================================================
Address to the *other* IO on subnet0: 172.16.1.1
Local address on subnet0: 172.16.0.129/255.255.248.0 (00:20:CE:C9:93:D2)
My io-index: 1
Boot-partition: /dev/sda1,ext2 (hd0,0)
Root/loadingGroup devices: /dev/sda, /dev/sda
External interface data: 00:20:CE:C9:93:D0=134.138.187.54/255.255.248.0,
DRBD device size: 132000000
=========================================================
Is it OK to go on with these values (NO/yes)?
yes

DONE!
--- End: Example printout ---

    reboot  (Reboot IO1)

    IO1 will be booted from RAM-disk and then IO1 will be upgraded.
    After the upgrade has finished, IO1 will be rebooted again, automatically.
    "Starting HybridIoSwGuard WARNING: /boot not exported", received on serial
    console. OK??!!

    One of the printouts before rebooting again:
      "TSP4/5 Hybrid installation finished, rebooting ..."

    After the second reboot, you will get a login prompt on the serial console.

- Log in to IO1 as telorb user (not from serial console) and verify that IO1 has
  become secondary IO:
    ssh -X telorb@toXXio1  (Adjust toXX to valid TSP system)
    Password: telorb       (Observe that the password has been changed!)
    cat /proc/drbd

--- Start: Printout example ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
    ns:0 nr:314304 dw:314304 dr:0 al:0 bm:146 lo:0 pe:0 ua:0 ap:0
        [>...................] sync'ed:  0.3% (128600/128906)M
        finish: 5:04:49 speed: 6,932 (5,132) K/sec
--- End: Printout example ---

- Only valid for NSP 5.0: If the system is an NSP 5.0 system, hardware wise,
    it is possible to speed up the DRBD synching via the Gigabit link,
    which is connected between the IO processors (en-1, eth3).
      To accomplish this, perform the following:

  Note: The instructions in this section are not yet valid!!!
        However, if you speed up the sync rate without having
        eth3 configured on the IOs, this will speed up the
        syncing a little bit anyway.

      Make sure the Gigabit link between IO1 (eth3) and IO2 (eth3) is physically
      connected, and then verify that it is configured as follows:
        On IO:
          /sbin/ifconfig -a  (Verify that inet addr for eth3 is configured)

        If not configured (info from uabnick) (not yet tested):
        From IO1:
          ifconfig eth3 down
          ifconfig eth3 192.11.0.1 netmask 255.255.255.0 up

        From IO2:
          ifconfig eth3 down
          ifconfig eth3 192.11.0.2 netmask 255.255.255.0 up

      Speed up the sync rate from IO2 (primary IO):
      o Verify that IO2 is primary (which it should be):
          su -
          Password: rootroot
          drbdsetup /dev/drbd0 state
          If the output is "Primary/Secondary", IO2 is primary.
      o Show the sync rate "Syncer options: rate" (among other things):
          drbdsetup /dev/drbd0 show
      o Set the synchronization speed to 30MBytes/second (default value: 8M)
          drbdsetup /dev/drbd0 syncer -r 30M
      o Show the sync rate:
          drbdsetup /dev/drbd0 show
      o Wait until the synchronization is finished.
        You can monitor the synchronization by entering the following command
        repeatedly:
          cat /proc/drbd

      o When the sychronization is finished, restore the synchronization speed
        back to the default value 8MBytes/second:
          drbdsetup /dev/drbd0 syncer -r 8M
        DO NOT FORGET TO RESTORE!!!
      o Show the sync rate:
          drbdsetup /dev/drbd0 show
      o Leave su mode:
          exit

      During the synchronization, the cat command will result in
      something like the following:
--- Start printout from IO1 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
    ns:0 nr:708124 dw:708124 dr:0 al:0 bm:170 lo:0 pe:0 ua:0 ap:0
        [>...................] sync'ed:  0.6% (128215/128906)M
        finish: 7:00:48 speed: 5,164 (4,944) K/sec
--- End printout from IO1 ---

--- Start printout from IO2 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:1345772 nr:0 dw:308072 dr:1345238 al:143 bm:476 lo:0 pe:0 ua:0 ap:0
        [>...................] sync'ed:  1.1% (127592/128906)M
        finish: 6:12:52 speed: 5,824 (4,872) K/sec
 1: cs:Unconfigured
--- End printout from IO2 ---

      When the synchronization is ready, the cat command will result in
      something like the following:
--- Start printout from IO1 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:Connected st:Secondary/Primary ld:Consistent
    ns:0 nr:132193144 dw:132193144 dr:0 al:0 bm:8184 lo:0 pe:0 ua:0 ap:0
--- End printout from IO1 ---

--- Start printout from IO2 ---
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:Connected st:Primary/Secondary ld:Consistent
    ns:132193148 nr:0 dw:500560 dr:132000126 al:143 bm:8451 lo:0 pe:0 ua:0 ap:0
 1: cs:Unconfigured
--- End printout from IO2 ---

- Wait for IO1 to synchronize from IO2. Check the progress either
  from IO1 or IO2:
    cat /proc/drbd

Note: It is of the utmost importance not to proceed with these instructions
      until the synchronization of IO1 has finished!

- The processor consoles have been closed, so new ones should be opened from
  IO1:
    STS_console --font 6x10 --max 99

    Not possible to open STS_console with the command parameters above!
    "Uncaught exception from user code:
        No config file found! at /opt/telorb/bin/STS_console line 129."??!!

* The following printouts start appearing in all Dicos processor logs, and they
  keep on coming on a regular basis:
      :
    nmbOfTestedIpAddrM = 2
    nmbOfTestedIpAddrM = 2
    nmbOfTestedIpAddrM = 2
    nmbOfTestedIpAddrM = 2
      :
  Is this OK or not??!! (RPC driver=OU/D96)

- Should new keys be generated to be able to use `ssh io1' and `ssh io2',
  respectively, without having to enter passwords??!!

- Still had 100% load in the Linux processor Proc_m0_s11 and it had reloaded
  three times and Proc_m0_s11 had reloaded spontaneously at 18:14, 01:37,
  09:00.

    --- Start: Printouts from Proc_m0_s11 ---
[24583] 2005-11-17 08:03:16 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
Please be patient it can take some times...mount: RPC: Unable to receive; errno = Connection refused
Thu Nov 17 08:03:22 2005
Remount: [mount -t nfs -o soft -o intr 172.16.8.129:/opt/mirror/reporterLogs /reporterLogs/], rc = 0x2000
mount: RPC: Unable to receive; errno = Connection refused
Thu Nov 17 08:03:22 2005
Remount: [mount -t nfs -o soft -o intr 172.16.8.129:/opt/mirror/applog /opt/telorb/axe/applog/], rc = 0x2000
mount: 172.16.1.1:/opt/mirror/reporterLogs2 failed, reason given by server: No such file or directory
Thu Nov 17 08:03:22 2005
Remount: [mount -t nfs -o soft -o intr 172.16.1.1:/opt/mirror/reporterLogs2 /reporterLogs2/], rc = 0x2000
mount: RPC: Unable to receive; errno = Connection refused
Thu Nov 17 08:03:22 2005
Remount: [mount -t nfs -o soft -o intr 172.16.8.129:/opt/mirror/mysql-data /opt/telorb/axe/mysql-data/], rc = 0x2000
LOG_ERR: ScriptRpmSupervisor.cc:283 [SCC/D126 R1E04]  Restarting RPM: omnidaemon-4.1-1
LOG_ERR: DeedugCentral.cci:237 [SCC/AXG73 R1O02a]  Static process restarted with id 617426
Starting omnidaemon: [25696] 2005-11-17 08:03:22 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
[25696] 2005-11-17 08:03:22 Err.: Invalid value in AnnotationDb keyword: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/writable
[25696] 2005-11-17 08:03:22 Err.: Filesystem object specified by LibraryPath not found: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/sys_structure.conf, No such file or directory
[  OK  ]
-----> RPM: omnidaemon-4.1-1 started

[25696] 2005-11-17 08:03:22 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
Change the permissions to telorb for /opt/telorb/axe/mysql-data
OM_IRP.init: org.omg.CORBA.OBJECT_NOT_EXIST: 
  Could not locate the following Object:
	 repository id : IDL:omg.org/CosNaming/ExtendedNamingContextFactory:1.0
	   object name : OAMNamingService
  minor code: 0  completed: No
LOG_ERR: ScriptRpmSupervisor.cc:283 [SCC/D126 R1E04]  Restarting RPM: omnidaemon-4.1-1
LOG_ERR: DeedugCentral.cci:237 [SCC/AXG73 R1O02a]  Static process restarted with id 617426
Starting omnidaemon: [  OK  ]
-----> RPM: omnidaemon-4.1-1 started

[26486] 2005-11-17 08:03:28 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
[26486] 2005-11-17 08:03:28 Err.: Invalid value in AnnotationDb keyword: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/writable
[26486] 2005-11-17 08:03:28 Err.: Filesystem object specified by LibraryPath not found: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/sys_structure.conf, No such file or directory
[26486] 2005-11-17 08:03:28 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
Change the permissions to telorb for /opt/telorb/axe/mysql-data
LOG_ERR: ScriptRpmSupervisor.cc:283 [SCC/D126 R1E04]  Restarting RPM: omnidaemon-4.1-1
LOG_ERR: DeedugCentral.cci:237 [SCC/AXG73 R1O02a]  Static process restarted with id 617426
Starting omnidaemon: [27282] 2005-11-17 08:03:33 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
[27282] 2005-11-17 08:03:33 Err.: Invalid value in AnnotationDb keyword: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/writable
[27282] 2005-11-17 08:03:33 Err.: Filesystem object specified by LibraryPath not found: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/sys_structure.conf, No such file or directory
[  OK  ]
-----> RPM: omnidaemon-4.1-1 started

[27282] 2005-11-17 08:03:33 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
LOG_ERR: ScriptRpmSupervisor.cc:283 [SCC/D126 R1E04]  Restarting RPM: omnidaemon-4.1-1
LOG_ERR: DeedugCentral.cci:237 [SCC/AXG73 R1O02a]  Static process restarted with id 617426
Starting omnidaemon: [28119] 2005-11-17 08:03:38 Err.: gethostbyname failed for hn0, Resource temporarily unavailable
[28119] 2005-11-17 08:03:38 Err.: Invalid value in AnnotationDb keyword: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/writable
[28119] 2005-11-17 08:03:38 Err.: Filesystem object specified by LibraryPath not found: /opt/telorb/axe/loadingGroup01_1/mirrored/config/ALEX/sys_structure.conf, No such file or directory
Change the permissions to telorb for /opt/telorb/axe/mysql-data
[  OK  ]
-----> RPM: omnidaemon-4.1-1 started
    --- End: Printouts from Proc_m0_s11 ---

  On Proc_m0_s11 (Linux):
    mount
      /dev/ram0 on / type ext2 (rw)
      none on /proc type proc (rw)
      none on /dev/pts type devpts (rw,gid=5,mode=620)
      nodev on /tmp type tmpfs (rw,mode=1777,nr_inodes=128k,nr_blocks=128k)
      nodev on /usr type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
      nodev on /var type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
      nodev on /opt type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
      io2:/opt/mirror/loadingGroup01_2 on /opt/telorb/axe/loadingGroup01_2 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.1.1)

  Since Proc_m0_s11 has reloaded, the mount points which do not seem to be
  available is really not available, even though they show up on Proc_m0_s13
  as mounted. They are actually not available there either.
    (ls -l /opt/telorb/axe/applog does not work from the Linux processors)

  On Proc_m0_s13 (Linux):
    mount
      /dev/ram0 on / type ext2 (rw)
      none on /proc type proc (rw)
      none on /dev/pts type devpts (rw,gid=5,mode=620)
      nodev on /tmp type tmpfs (rw,mode=1777,nr_inodes=128k,nr_blocks=128k)
      nodev on /usr type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
      nodev on /var type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
      nodev on /opt type tmpfs (rw,mode=0755,nr_inodes=128k,nr_blocks=128k)
      io1:/opt/mirror/loadingGroup01_1 on /opt/telorb/axe/loadingGroup01_1 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.0.129)
      io2:/opt/mirror/loadingGroup01_2 on /opt/telorb/axe/loadingGroup01_2 type nfs (rw,rsize=8192,wsize=8192,timeo=14,soft,intr,retry=3,addr=172.16.9.1)
      172.16.8.129:/opt/mirror/applog on /opt/telorb/axe/applog type nfs (rw,soft,intr,addr=172.16.8.129)
      172.16.1.1:/opt/mirror/tsp/NM/Logging/mysql-data on /opt/telorb/axe/mysql-data type nfs (rw,soft,intr,addr=172.16.1.1)
      172.16.1.1:/opt/mirror/tsp/NM/PMF/reporterLogs on /reporterLogs type nfs (rw,soft,intr,addr=172.16.1.1)

  No designer available for troubleshooting.

- Physically, connect a serial link to IO2, to be able to monitor it during
  the upcoming reboot, in case anything goes wrong.

- Reboot IO2 (to get IO1 to become primary for the mountings further down
  to take effect):
    su root
    Password: rootroot
    reboot

Note: loadingGroup01_1 will not be available from now on until it is mounted
      in the next step. Additionally, loadingGroup01_2 will not be available,
      since IO2 is secondary.
      This is not acceptable??!! If e.g. a processor reload occurs, the
      processor will not be able to reload, and if two processors reload
      simultaneously, there will be a zone reload which will fail!!

    After the reboot, you will get a login prompt on the serial console.

    Observation: Lots of STS messages in the processor logs (pointing out
                 different processors):
                 "Message from syslogd@Proc_m1_s1 at Thu Nov 17 13:35:33 2005 ...
                  Proc_m1_s1 STSsw: Could not flush all data to Proc_m1_s15:Inappropriate ioctl for device"

- Log in to IO2 as telorb user (not from serial console) to verify that it is
  up and running:
    ssh -X telorb@toXXio2  (Adjust toXX to valid TSP system)
    Password: telorb
    cat /proc/drbd
      Should be "Secondary/Primary".

- On IO1, verify that IO1 has become primary IO (can be seen in the previous
  command, but anyway):
    cat /proc/drbd
      Should be "Primary/Secondary".

- At this stage, no mount points are available, which is indicated by alarms.

- Perform re-mount towards IO1:
    All traffic processors (TPs) must be ordered to re-mount towards IO1.
    This is achieved in different ways depending on if Dicos OS or Linux OS
    is executing on the TP.

    In the TelORB Manager's "DNS/NFS" card, "File System Configuration"
    area, click "Refresh".
      All mount points should be red-marked, i.e. "loadingGroup01_1",
      "loadingGroup01_2", "upgradePackages" and NM mount points.

    To re-mount all Dicos processors, execute the following script on IO2:
      cd /opt/telorb/axe/scripts
      ./remount2IO.exp 172.16.0.9 8002 1 172.16.0.129 172.16.8.129
             (172.16.0.9 = IP address of 1st Dicos loader processor,
              8002 = port to access 1st Dicos loader processor,
              1 = IO1,
              172.16.0.129 = IP address for subnet A for IO,
              172.16.8.129 = IP address for subnet B for IO)

    --- Start: Printouts from Proc_m0_s11 ---

spawn telnet 172.16.0.9 8002
Trying 172.16.0.9...
Connected to 172.16.0.9.
Escape character is '^]'.
No registred users. Free access.
TelORB shell - welcome

$ /> cd CLI/NFS

$ /CLI/NFS> sendFScmd umount /loadingGroup01_1
Operation succeeded.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc1 /loadingGroup01_1/ /opt/mirror/loadingGroup01_1
Operation succeeded.

$ /CLI/NFS> sendFScmd umount /upgradePackages
Operation succeeded.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/mirror/upgradePackages
Operation failed on 1 processors with errno 11.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/mirror/upgradePackages
Operation failed on all processors with errno 11

$ /CLI/NFS> sendFScmd umount /reporterLogs
Operation failed on 2 processors for an unknown reason.

$ /CLI/NFS> sendFScmd umount /reporterLogs
Command failed - CORBA System Exception - commFailure exception
File system operation failed

$ /CLI/NFS> sendFScmd umount /opt/telorb/axe/mysql-data
Command failed - CORBA System Exception - commFailure exception
File system operation failed

$ /CLI/NFS> 
    --- End: Printouts from Proc_m0_s11 ---

      Zone reload!!!
      
Proc_m0_s9:

LOG_ERR: ALARM: [type=2, severity=5, key=(LOGGING, Logging, 0), cause=/opt/telorb/axe/applog/applog.ApplicationList (No such file or directory), time=2005-11-17 14:29:02]
LOG_ERR: ALARM: [type=2, severity=2, key=(LOGGING, Logging, 0), cause=/opt/telorb/axe/applog/applog.ApplicationList (No such file or directory), time=2005-11-17 14:29:03]
-----> Lost link through Ethernet B to [1.1.27]
-----> Lost link through Ethernet A to [1.1.27]
LOG_CRIT: IPC: Lost contact with [1.1.27]
DEBUG INFO: PCFmaster_tcap_itu_TotalImpl::handleAbortion
LOG_ERR: DswcmConfigurationManagerAgentDialogue.cc:446 [OU/AXG2154 R2M07] Connection lost to CM Agent: 1.27
LOG_NOTICE: CM: Starting unplanned re-configuration for processor: 1.27
-----> Lost link through Ethernet A to [1.1.25]
-----> Lost link through Ethernet B to [1.1.25]
LOG_CRIT: IPC: Lost contact with [1.1.25]
DEBUG INFO: PCFmaster_tcap_itu_TotalImpl::handleAbortion
DcfSocketGroup receive DcfIpcErrorEvent: 3000000
LOG_ERR: DswcmConfigurationManagerAgentDialogue.cc:446 [OU/AXG2154 R2M07] Connection lost to CM Agent: 1.25
LOG_NOTICE: CM: Performing a zone reload 

Reason: Multiple processor failure
-----> Lost link through Ethernet B to [1.1.2]
-----> Lost link through Ethernet B to [1.1.1]
-----> Lost link through Ethernet B to [1.1.9]
-----> Lost link through Ethernet A to [1.1.9]


Proc_m3_s1 which crashed:

nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
Warning! WriteXmlToFileThread is interrupted!
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
DEBUG INFO: Pm_J_Error   --> (0x115e9f) PmReporter::WriteXmlToFileThread::run() - Could not write: /reporterLogs/PlatformMeasures/A20051117.1230-1235_jambala_PlatformMeasures
Returned error: /reporterLogs/PlatformMeasures/A20051117.1230-1235_jambala_PlatformMeasures
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
-----> Established link through Ethernet B to [1.1.102]
-----> Established link through Ethernet A to [1.1.102]
nmbOfTestedIpAddrM = 2
LOG_NOTICE: Rpc working properly, rpc6
DicosSyslog: new levels: 5 5
DicosApplog: new levels: 7 5
LOG_NOTICE: Rpc working properly, rpc2
LOG_NOTICE: Rpc working properly, rpc9
nmbOfTestedIpAddrM = 2
  :
nmbOfTestedIpAddrM = 2
DEBUG INFO: OamProvisioningCounter::getInstance
DEBUG INFO: PmOamProvisioningCounter::PmOamProvisioningCounter
DEBUG INFO: *** Class Name : FTU
DEBUG INFO: PmOamProvisioningCounter::~PmOamProvisioningCounter
DEBUG INFO: DicosTimer deleted in ~PmOamProvisioningCounter
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
Warning! WriteXmlToFileThread is interrupted!
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
   ---------- TimeHandler maintenance interval ----------
        UTC time:    2005-11-17 12:41:51.646
        Local time:  2005-11-17 13:41:51.646
   ------------------------------------------------------
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
nmbOfTestedIpAddrM = 2
DEBUG INFO: Pm_J_Error   --> (0x5b4dd7) PmReporter::WriteXmlToFileThread::run() - Could not write: /reporterLogs/PlatformMeasures/A20051117.1235-1240_jambala_PlatformMeasures
Returned error: /reporterLogs/PlatformMeasures/A20051117.1235-1240_jambala_PlatformMeasures
Warning! WriteXmlToFileThread is interrupted!
  :

No crash reason info in 1.1.27 nor in 1.1.25!

DicosCapsuleTextDump.172.16.0.9-1 empty!

Reran the script:
spawn telnet 172.16.0.9 8002
Trying 172.16.0.9...
Connected to 172.16.0.9.
Escape character is '^]'.
No registred users. Free access.
TelORB shell - welcome

$ /> cd CLI/NFS

$ /CLI/NFS> sendFScmd umount /loadingGroup01_1
Operation succeeded.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc1 /loadingGroup01_1/ /opt/mirror/loadingGroup01_1
Operation succeeded.

$ /CLI/NFS> sendFScmd umount /upgradePackages
Operation succeeded.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/mirror/upgradePackages
Operation succeeded.

$ /CLI/NFS> sendFScmd umount /reporterLogs
Operation succeeded.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc6 /reporterLogs/ /opt/mirror/reporterLogs
Operation succeeded.

$ /CLI/NFS> sendFScmd umount /opt/telorb/axe/mysql-data
Operation succeeded.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc9 /opt/telorb/axe/mysql-data/ /opt/mirror/mysql-data
Operation succeeded.

$ /CLI/NFS> sendFScmd umount /opt/telorb/axe/applog
Operation succeeded.

$ /CLI/NFS> sendFScmd mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc7 /opt/telorb/axe/applog/ /opt/mirror/applog
Operation succeeded.

$ /CLI/NFS> quit
Connection closed by foreign host.


      (An alternative way to re-mount all Dicos processors is to perform the
      umount and mount commands as follows (only CW/OS considered below):
      In the TelORB Manager's "DNS/NFS" card, "File System Command"
      input field, enter the following (verify the IP addresses before using
      the mount commands below):
      umount /loadingGroup01_1 followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.
        -and-
      mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc1 /loadingGroup01_1/ /opt/mirror/loadingGroup01_1 followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.

      umount /upgradePackages followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.
        -and-
      mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/mirror/upgradePackages followed by Enter/Return.
      Wait for the result popup window "Operation succeeded." Click OK.

      Also consider Dicos processor re-mounting for NM mount points.

    Verify the Dicos processor re-mounting, by clicking Refresh in the
    TelORB Manager's "DNS/NFS" card, "File System Configuration" area.
        "nfs  /loadingGroup01_1...", "nfs  /upgradePackages...", "...applog",
        "...mysql-data" and "...reporterLogs" should be green-marked.
        "nfs  /loadingGroup01_2..." and "...reporterLogs2" should be
        red-marked.

      Note: "/loadingGroup01_2" and "/reporterLogs2" should not actually be
            mounted. They should be unmounted (removed) later on, but are
            not!!.

    Also consider Dicos processor re-mounting for any application mountings.

    To re-mount all Linux processors (excluding IOs and FSs), perform disable
    and enable (reload) of each processor as described below:
    In the TelORB Manager's "Processors" card, disable and enable all Linux
    processors, one by one.

- To e.g. be able to fetch the TSP 5 Runtime Environment outside the IO
  processor, follow the instructions provided in
  Mount EAB CW/OS lab environment on IOs.

- Copy the TSP 5 Runtime Environment to IO1 (for SS7 steps later on).
  Use LSV26 for TSP5 runtime.

  On IO1:
    cd /opt/telorb/axe
    mkdir runtimes
    cd runtimes
    cp -r /ipims_dicos/ipims_dicos10/dists/TSP5.2/LSV26/TSP-5.2-LSV26-0-0 .
    (chmod -R +w TSP-5.2-LSV26-0-0)
    (chown telorb:telorb -R TSP-5.2-LSV26-0-0)
    cd /opt/telorb/axe/runtimes
    echo "TSP-5.2-LSV26-0-0" > runtime_order.list

- SS7 step.
  Re-install DCM on IO1:
    su -
    Password: rootroot
    eprtsetup
    rpm -i `epgetpath LM/CXC1328123`/bin/SS7DCMLM.LM_CXC1328123.Code*
      Error printout:
        "/var/tmp/rpm-tmp.87200: line 38: /etc/httpd/conf/alias.conf: No such file or directory
      dcmrpm NOTE: Apache alias file updated."
      OK??!!

    cp /data/ss7/cnf/*.dcm /opt/DCM
    rm -fr /data/ss7
    chown -R telorb:telorb /opt/DCM
    exit
    exit   Why twice??!!

- SS7 step.
  Re-install LogDaemon on IO1:
    su -
    Password: rootroot
    eprtsetup
    rpm -i `epgetpath LM/CXC1328124`/bin/SS7LOGDLM.LM_CXC1328124.Code.R2A78.i686-linux
    rm /opt/telorb/etc/rc.d/init.d/logdaemonrpm.sh
    rm -fr /data/logging
    chown -R telorb:telorb /opt/telorb/logd
    exit
    exit   Why twice??!!

    cd /opt/telorb/logd
    ln -s /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/cp*.cnf cp.cnf
    XXX
    XXX











exit

exit

---
cd /opt/telorb/logd

ln -s /opt/telorb/axe/loadingGroup01_1/mirrored/cnf/cp*.cnf cp.cnf


Mooore...



exit



The mountings for Linux processors does not seem correct:

172.16.8.129:/opt/mirror/tsp/applog on /opt/telorb/axe/applog type nfs (rw,soft,intr,addr=172.16.8.129)


Step 3 is now completed.

(Should the GESB/SCB loadable software (firmware) be upgraded??!!
 No! Nothing has been changed!)


Step 4 CW/OS only - Redundancy Upgrade
======================================

/data setting!!!!!!!!!!!!

Create backup!!!!!!!!!!!!


Since no generic upgrade packages for the upgrade path steps are currently
available, on e.g. CD/DVD, you have to build the upgrade package for this
step yourself.
These instructions, describe how to build upgrade packages on tos2.
To be able to access IO1 from tos2, a special mounting is required....


Prepare epct file(s) to be used when building the upgrade package for step 4
----------------------------------------------------------------------------
New epct files, which are based on the TSP 5.0 epct template files, have
to be created with the input from the existing TSP 4 based epct file(s).

Instructions for creating TSP5 based epct files:

You may fetch a TSP 5.0 epct template file for e.g. NSP 5.0 DicosMax, including
NetRed, NM and Diameter stuff, from the following location:
  /ipims_dicos/ipims_dicos10/dists/TSP5.2/LSV24/TSP-5.2-LSV24-0-0/config/epct/NSP5.x/Maxi/DicosMax_NetRed

To be considered:

NetRedMonitorsPool for both Dicos loaders?


--- Start: Notes for my own memory ---
  (The epct files for TSP4 for system to14 are located at
  /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp4rm453mcp3/initialstart_cwos_to14/)
  (The epct files for TSP5 for system to14 are located at
  /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/)
  (Copied qperulf's TSP5/NSP4.x epct files to the directory above:
  cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/
  scp /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4/E00NodeType.epct.orig .
  scp /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4/E10cwos_initial.epct .
  scp /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4/E10Name.epct .
  scp /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4/extra.epct .
  scp /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4/r14_linux_refapp.epct .
  scp /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4/tspRefApp.epct .
  scp /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4/vip.epct .)
  (Also copied to21's TSP5/NSP5.0 epct files to the directory above:
  cd /home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/
  scp telorb@to21io2:/var/opt/tsp/epct/E10Name.epct .
  scp telorb@to21io2:/var/opt/tsp/epct/E10cwos_initial.epct .
  scp telorb@to21io2:/var/opt/tsp/epct/E20ss7.epct .
  scp telorb@to21io2:/var/opt/tsp/epct/E00NodeType.epct .
  scp telorb@to21io2:/var/opt/tsp/epct/E30nm.epct .
  scp telorb@to21io2:/var/opt/tsp/epct/TSPRefAppMaxiDicosMax.epct .
  scp telorb@to21io2:/var/opt/tsp/epct/mountAll .)
  (Used the to21 epct files as templates for the to14 epct files)
--- End: Notes for my own memory ---

Modify E00NodeType.epct (or corresponding):
- Consider processor types and amount of processors.

- Remove the following IDP:
    SOFTWARE CXP9010516/1;        // AppTrace_IDP,     Application Trace support

- Add the following IDP (preferably in an additional epct file (e.g. UDC.epct),
                         since UDC will be removed in step 5):
    SOFTWARE IDP/D36;  // UDCRemoteServer

- Add the following pool to all Dicos processors (preferably in an additional
                                                  epct file (e.g. UDC.epct),
                                                  since UDC will be removed in
                                                  step 5) (same as in epct file
                                                  for TSP4):
    DicosUDCRemotePool

- Add the following pool to all Linux processors:
    DicosNetRedPool

- Make sure that
    SOFTWARE CXP901394/1;     	// TelorbLinux_IDP,	Linux base software
  is stated before
    SOFTWARE CXP901307/1;     	// NetRed_IDP, 		DBN Network Redundant node (Optional)
  in the epct file.

- If File Servers are used, add File Server data:
  If the TSP system is equipped with File Server(s), the following should be
  added to the epct file, after FILESERVER_PAIRS (which specifies the IO
  processors), e.g.:
    FILESERVERS="Proc_m0_s1 Proc_m0_s5 Proc_m1_s5 Proc_m3_s1"


- Use the same epct for RefApp as in TSP4, i.e.
    SOFTWARE IDP/DEM101;
  and the same pool names as used for TSP4.

- Modify E10cwos_initial.epct, if you find it necessary.

- Modify other epct files, if you find it necessary.

-- -- --

Copy the created epct files to e.g. tos2, if not already done:
  From tos2:
  cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/step4
  scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/to14_E00NodeTypeDicosMaxNSP5WithoutNMandSS7_noAppTraceIDP_midi.epct .
  Password: tsP4ever
  scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/to14_E10cwos_initial.epct .
  scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/to14_E10Name.epct .
  scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/to14_udc_midi.epct .
  scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/to14_r14_linux_extra_config_to14.epct .
  scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/to14_r14_linux_vip_to14.epct .
  scp telorb@134.138.186.45:/home/uabmsu/telorb/upgradepath_tsp4to5/wp051/tsp5/upgrade/to14_r14_linux_refapp_to14.epct .


Build upgrade package for step 4
--------------------------------
Step 4: It is enough to use tbWP073. Add TLMs separately below, if any.

From the TelORB Manager's "Inventory" card, create a .config file from
the system. This file will be used when building the upgrade package with
the epct command further down in these instructions.
The .config file will end up in directory /opt/telorb/axe/loadingGroup01_1/
on IO1.

Open a new shell to build the upgrade package from and enter the following:
  ssh -X telorb@tos2
  Password: tsP4ever

  cd /home/dicostest/tosFiles/to14/upgradepath/step4
  rm -rf *

  Copy the previously created .config file from IO1 to tos2:
  scp telorb@toXXio1:/opt/telorb/axe/loadingGroup01_1/step2.config . 
  Password: telorb

  cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/step4

  mkdir epws  (If not already done)

  source /ipims_dicos/BS2/tbWP073/Setup.csh

  setenv EP_WORKSPACE `pwd`/epws

  epconfig delete -a

  Check if there are any TLMs to be used:
    ls -l /home/dicoshack/Hack/WP051/step4/

      If there are TLMs, then:
        epconfig set -r /home/dicoshack/Hack/WP051/step4/

  Add other TLMs, if any:
    epconfig set -r ...

  Note: Observe the "U" flag in the epct command below. It is required
        when building the upgrade package for step 4.

  epct -d /home/dicostest/tosFiles/to14/upgradepath/step4 -XvFcU -u /home/dicostest/tosFiles/to14/upgradepath/step4/step2.config to14_E10Name.epct to14_E00NodeTypeDicosMaxNSP5WithoutNMandSS7_noAppTraceIDP_midi.epct to14_E10cwos_initial.epct to14_r14_linux_extra_config_to14.epct to14_r14_linux_vip_to14.epct to14_r14_linux_refapp_to14.epct to14_udc_midi.epct

--- Start: Example printout ---
 Upgrade method: DicosRedundancyReboot caused by LM/D324 
 The generated upgrade package step4 consists of :
      created IDP(s): CXP9010510/1 CXP901293/1 CXP9011426/1 CXP9011424/1 CXP9011423/1 
      replaced IDP: IDP/D22 -> CXP901317/1
      replaced IDP: IDP/MD14 -> CXP901292/1
      replaced IDP: IDP/MD16 -> CXP901299/1
      replaced IDP: IDP/D13 -> CXP901303/1
      replaced IDP: IDP/D16 -> CXP901294/1
      replaced IDP: IDP/MD18 -> CXP901309/1
      replaced IDP: IDP/SU1 -> CXP901394/1
      replaced IDP: IDP/D30 -> CXP901495/1
      replaced IDP: IDP/D38 -> CXP901441/1
      replaced IDP: IDP/D2 -> CXP901307/1
      changed IDP(s): IDP/DEM101 IDP/D36 
      removed IDP(s): IDP/DUO2 IDP/MD11 IDP/D32 IDP/D35 IDP/D48 IDP/D49 
      created LM(s): LM/D324 LM/D355 LM/D331 LM/D391 LM/D277 LM/D310 LM/D260 LM/D382 LM/D323 LM/D267 LM/D303 LM/D309 LM/D311 LM/D248 LM/D255 LM/D256 LM/D258 LM/D257 LM/D271 LM/D295 LM/D263 LM/D296 LM/D394 
      changed LM: LM/D25 (R1N11 -> R2C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG462 (R3B01 -> R2D01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG676 (R1AC11 -> R2J01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG705 (R3B11 -> R2D01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG967 (R1Z11 -> R2L01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG904 (R1Y11 -> R2F01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG968 (R1AB11 -> R2L01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/DUO4 (R1AB11 -> R2H01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG600 (R1L02 -> R2C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D356 (R1A02 -> R1C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/DUO7 (R1M02 -> R2E01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG490 (R1L03 -> R2C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG828 (R1V11 -> R2C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG426 (R1I02 -> R2B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D37 (R1Z11 -> R2D01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG591 (R3A01 -> WP073_R2F01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D11 (R1X11 -> R2C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG673 (R1T11 -> WP051_R2F01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD11 (R1N11 -> R2C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD36 (R1J11 -> R2B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD32 (R1I02 -> R2A02)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD7 (R1V11 -> WP051_R2C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D38 (R1Z11 -> R3B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD40 (R1AB11 -> R2F01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD27 (R1AA11 -> R4B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D52 (R1L11 -> R2B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD38 (R1AA11 -> R2G01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG730 (R1Z11 -> R2F01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG731 (R1K02 -> R2D01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG732 (R1Z11 -> R3B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD37 (R2M11 -> R3G01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/AXG1006 (R1AA11 -> R2H01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D63 (R1E11 -> R2A02)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D65 (R1F11 -> R2A02)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D55 (R1I01 -> R2A03)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D89 (R1N11 -> WP051_R2G01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D97 (R2ZB11 -> WP051_R3H01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D110 (R1K11 -> R4B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D112 (R2AD11 -> WP051_R3J01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D270 (R2B11 -> R1B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D61 (R1S11 -> R2B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D62 (R1K11 -> R2B01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D298 (R2A01 -> R1A02)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D329 (R2A02 -> R1A03)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D318 (R2A01 -> R1D01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/MD39 (R1N11 -> R2E01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D327 (R2A01 -> R1A02)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D330 (R2A01 -> R1A02)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D334 (R2A01 -> R1C01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/D387 (R1A02 -> R1A01)    also moved from IDP/MD14 to CXP9010510/1
      changed LM: LM/DUO12 (R1N01 -> R2B01)    also moved from IDP/DUO2 to CXP901293/1
      changed LM: LM/DUO13 (R1I03 -> R2C01)    also moved from IDP/DUO2 to CXP901293/1
      changed LM: LM/D83 (R1H11 -> R3B01)    also moved from IDP/D22 to CXP901317/1
      changed LM: LM/D176 (R1U11 -> R2E01)    also moved from IDP/D22 to CXP901317/1
      changed LM: LM/D200 (R1M11 -> WP073_R2A02)    also moved from IDP/D22 to CXP901317/1
      changed LM: LM/D114 (R2AE11 -> WP051_R3K01)    also moved from IDP/MD14 to CXP9011426/1
      changed LM: LM/D212 (R1M11 -> WP051_R2E01)    also moved from IDP/D32 to CXP9011426/1
      changed LM: LM/D238 (R1F11 -> WP051_R2G01)    also moved from IDP/D32 to CXP9011426/1
      changed LM: LM/D216 (R1H11 -> WP051_R2E01)    also moved from IDP/D32 to CXP9011426/1
      changed LM: LM/D250 (R1G11 -> WP051_R2G01)    also moved from IDP/D32 to CXP9011426/1
      changed LM: LM/D390 (R1A02 -> R1C01)    also moved from IDP/D35 to CXP9011426/1
      changed LM: LM/D261 (R1C11 -> R2D01)    also moved from IDP/D35 to CXP9011426/1
      changed LM: LM/D328 (R2A01 -> R1C01)    also moved from IDP/D35 to CXP9011426/1
      changed LM: LM/D305 (R2A02 -> R1C01)    also moved from IDP/D35 to CXP9011426/1
      changed LM: LM/D161 (R1D11 -> WP073_R2C01)    also moved from IDP/D35 to CXP9011426/1
      changed LM: LM/D386 (R1A01a -> R2B01)    also moved from IDP/D35 to CXP9011426/1
      changed LM: LM/AXG561 (R4C11 -> WP051_R6A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG425 (R5C12 -> WP051_R6A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/MD5 (R1I01 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG436 (R3C11 -> R2K01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG702 (R1M11 -> R2C01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG685 (R1I01 -> R3B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG694 (R1Z11 -> R2D01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG693 (R1X11 -> R3B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG695 (R1K11 -> R3B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG810 (R1J01 -> R3B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG431 (R1J11 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG811 (R1I03 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG812 (R1I01 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/DUO21 (R1M11 -> R2C01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/MD10 (R1AD11 -> R2G01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/MD28 (R1K01 -> R2B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/MD29 (R1J11 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/MD30 (R2C11 -> R3C01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/MD35 (R1I01 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D13 (R1L01 -> R2C01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D45 (R1J01 -> R2C01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D47 (R1J -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D53 (R1K11 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D80 (R1D11 -> R2B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D60 (R1L11 -> WP051_R2C01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D64 (R1N11 -> R2E01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D70 (R1N11 -> R2E01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D71 (R1V11 -> R2H01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D72 (R1S11 -> R2E01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D73 (R1U11 -> R2G01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D74 (R1V11 -> R2G01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D111 (R1B11 -> R2C01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D249 (R1B11 -> R1B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D133 (R1V11 -> WP073_R4B01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/AXG800 (R1K02 -> R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/MD46 (R1L11 -> WP073_R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/D164 (R1C11 -> WP073_R2A01)    also moved from IDP/MD14 to CXP901292/1
      changed LM: LM/DUO20 (R1I01 -> R2B01)    also moved from IDP/MD16 to CXP901299/1
      changed LM: LM/D36 (R1L11 -> WP073_R2A01)    also moved from IDP/MD16 to CXP901299/1
      changed LM: LM/D56 (R1S11 -> R2B01)    also moved from IDP/D13 to CXP901303/1
      changed LM: LM/D66 (R1N11 -> R2E01)    also moved from IDP/D16 to CXP901294/1
      changed LM: LM/D69 (R1Y11 -> R2F01)    also moved from IDP/D16 to CXP901294/1
      changed LM: LM/MD47 (R3B11 -> R2J01)    also moved from IDP/MD18 to CXP901309/1
      changed LM: LM/MD48 (R1AD12 -> WP051_R2G01)    also moved from IDP/MD18 to CXP901309/1
      changed LM: LM/D8 (R1I01 -> R2D01)    also moved from IDP/MD18 to CXP901309/1
      changed LM: LM/D108 (R3A11 -> R4B01)    also moved from IDP/D32 to CXP9011424/1
      changed LM: LM/D232 (R1L11 -> R3G01)    also moved from IDP/D32 to CXP9011424/1
      changed LM: LM/D129 (R1J11 -> R2B02)    also moved from IDP/D32 to CXP9011424/1
      changed LM: LM/D162 (R1G11 -> R2C01)    also moved from IDP/D35 to CXP9011424/1
      changed LM: LM/D381 (R1A02 -> R1A01)    also moved from IDP/D35 to CXP9011424/1
      changed LM: LM/D140 (R1C03 -> WP073_R2A01)    also moved from IDP/D35 to CXP9011424/1
      changed LM: LM/D141 (R1U11 -> WP073_R2A01)    also moved from IDP/D35 to CXP9011424/1
      changed LM: LM/D85 (R4C02 -> WP051_R5B01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D137 (R1G01 -> R2A01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D117 (R1N11 -> R2I01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D86 (R1N11 -> WP051_R2U01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D151 (R2D11 -> R3E01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D153 (R1S11 -> R3C01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D177 (R1F11 -> R2H01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D233 (R2D11 -> R4B01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D236 (R1A02 -> R2A02)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D283 (R2A01 -> R1A02)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D299 (R2A01 -> WP051_R1F01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D333 (R2A01 -> WP051_R1A02)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D150 (R1D10 -> WP073_R2A01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D152 (R1S11 -> WP073_R2A02)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D214 (R1G11 -> WP073_R2A02)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D231 (R1D11 -> WP073_R2A01)    also moved from IDP/SU1 to CXP901394/1
      changed LM: LM/D124 (R1H11 -> R2B01)    also moved from IDP/D30 to CXP901495/1
      changed LM: LM/D158 (R1J11 -> R2D01)    also moved from IDP/D38 to CXP901441/1
      changed LM: LM/D90 (R1Z11 -> R2L01)    also moved from IDP/D38 to CXP901441/1
      changed LM: LM/D210 (R1B01 -> R2B01)    also moved from IDP/D38 to CXP901441/1
      changed LM: LM/D148 (R1M12 -> WP051_R2G01)    also moved from IDP/D38 to CXP901441/1
      changed LM: LM/D217 (R1B01 -> R2A01)    also moved from IDP/D38 to CXP901441/1
      changed LM: LM/D297 (R2A01 -> R1D01)    also moved from IDP/D38 to CXP901441/1
      changed LM: LM/D225 (R1K11 -> R2F01)    also moved from IDP/D48 to CXP9011423/1
      changed LM: LM/D304 (R2A01 -> R1E01)    also moved from IDP/D48 to CXP9011423/1
      changed LM: LM/D264 (R1A02a -> R1E01)    also moved from IDP/D48 to CXP9011423/1
      changed LM: LM/D5 (R1U11 -> WP051_R2G01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D6 (R3C01 -> R2G01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D7 (R1J11 -> R2C01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D12 (R1Y11 -> R2E01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D17 (R2Z11 -> R3H01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D20 (R1Y11 -> R2E01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D39 (R1X11 -> R2D01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D130 (R1S11 -> R4B01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D275 (R1E11 -> R3B01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D340 (R1A03 -> R1C01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/D383 (R1A02 -> R1B01)    also moved from IDP/D2 to CXP901307/1
      changed LM: LM/PRO101 (R1D11 -> R1D99)
      changed LM: LM/PRO201 (R2B11 -> R2B99)
      changed LM: LM/PRO301 (R2B11 -> R2B99)
      changed LM: LM/PRO401 (R2B12 -> R2B99)
      changed LM: LM/PRO402 (R2B11 -> R2B99)
      changed LM: LM/PRO501 (R2B11 -> R2B99)
      changed LM: LM/PRO601 (R1B11 -> R1B99)
      changed LM: LM/PRO701 (R2B11 -> R2B99)
      changed LM: LM/PRO411 (R2B11 -> R2B99)
      changed LM: LM/PRO412 (R2B11 -> R2B99)
      changed LM: LM/POT400 (R1B11 -> R1B99)
      changed LM: LM/PRO801 (R1B11 -> R1B99)
      changed LM: LM/D142 (R1E13 -> WP073_R2A02)
      changed LM: LM/D143 (R2B12 -> WP073_R3A01)
      changed LM: LM/D144 (R2D11 -> WP073_R3A01)
      removed LM(s): LM/DUO14 LM/D127 LM/D132 LM/D139 LM/D163 LM/DUO5 LM/MD26 LM/D96 LM/D178 LM/D179 LM/D180 LM/D181 LM/D182 LM/D183 LM/D201 LM/D226 LM/D247 LM/D239
  :
  :
      created POOL(s): CwosCommonPool CwosClusterControlPool CwosDbnPool 
      removed POOL(s): DicosDbReplicaPool DicosQnPool
--- End: Example printout ---

    (qperulf's epct command for building step 4:
    Run epct, e.g. ( i katalogen
    /home/dicoshack/Hack/qperulf/to29/WP51/RM453_MCP3/step4):
    epct -d /home/dicostest/tosFiles/to29/upgradepath/WP51/RM453_MCP3/step4 -XvFcU -u /home/dicostest/tosFiles/to29/upgradepath/WP51/RM453_MCP3/initialstart_step2/to29_tbAD14lp11_5_step2.config E10Name.epct E00NodeType.epct E10cwos_initial.epct r14_linux_refapp.epct vip.epct extra.epct)

  cd /home/dicostest/tosFiles/to14/upgradepath/step4
  ls -l
  The file "step4.config" and the directory "upgradePackages" should have been
  created.

  more /home/dicostest/tosFiles/to14/upgradepath/step4/upgradePackages/step4/upgradeConfigurationData/upgradeControlData.01
  more /home/dicostest/tosFiles/to14/upgradepath/step4/upgradePackages/step4/upgradeConfigurationData/upgradeControlData.02
  more /home/dicostest/tosFiles/to14/upgradepath/step4/upgradePackages/step4/upgradeConfigurationData/upgradeControlData.03
                (The file upgradeControlData.03 is an additional file only valid
                 for the step 4 upgrade)


Pack and upload the upgrade package to IO1
------------------------------------------
On tos2:
  cd /home/dicostest/tosFiles/to14/upgradepath/step4/upgradePackages
  tar zcf step4.tgz step4
  scp step4.tgz telorb@toXXio1:/opt/telorb/axe/upgradePackages
  Password: telorb           (Adjust toXX to valid TSP system)


Unpack the upgrade package on IO1
---------------------------------
On IO1:
  cd /opt/telorb/axe/upgradePackages
  tar zxf step4.tgz


Apply upgrade package "step4"
-----------------------------
In TelORB Manager's "Upgrades" card, click "Rescan" and then select "step4"
and click "Apply".

--- Start: Previous attempt 3 ---
DEBUG INFO: DlgCoTG_TotalImpl::alive was called
DEBUG INFO: DlgCoPop_TotalImpl::alive was called
DEBUG INFO: DlgCoPop_TotalImpl::alive was called
DEBUG INFO: DlgCoPop_TotalImpl::alive was called
DEBUG INFO: DlgCoTG_TotalImpl::alive was called
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
link_activate due to ACTIVATE_MSG1
-----> Established link <1.1.3:wm2-1.1.4:> on Network A
link_activate due to ACTIVATE_MSG1
-----> Established link <1.1.3:wm3-1.1.4:> on Network A
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
link_activate due to ACTIVATE_MSG1
-----> Established link <1.1.3:wm2-1.1.5:> on Network A
link_activate due to ACTIVATE_MSG1
-----> Established link <1.1.3:wm3-1.1.5:> on Network A
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: DeeNewParty_Impl.cc:105 [SCC/MD44 R1D01] State transfer failed for process type [DicosOutageMeasurementNetRedPT] due to communication problems between the 'new' and the 'old' process instances. 
LOG_ERR: DswomAvailabilityFSAgent.cc:114 [OU/D160 R1E01] dir loadingGroup01_1/Outage is already created
LOG_ERR: DswomAvailabilityFSAgent.cc:114 [OU/D160 R1E01] dir loadingGroup01_2/Outage is already created
DEBUG INFO: void DicosOutageMeasurementNetRedPT_Impl::systemStarted ()
DEBUG INFO: DicosOutageMeasurementPT_Impl starts ISPStat
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
-----> Starting central process(es) in DU(s) with id=1047938
DEBUG INFO: NRV: CwosNetRedVipPT_Impl::systemStarted ()
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
-----> Built replica for mdp ( 1047941, 2 )
-----> Built replica for mdp ( 1047941, 3 )
-----> Built replica for mdp ( 1047941, 0 )
  :
  :
-----> Built replica for mdp ( 1031889, 0 )
-----> Built replica for mdp ( 1048409, 0 )
-----> Starting central process(es) in DU(s) with id=1047795
DEBUG INFO: DicosFsMo_Pt_Impl::DicosFsMo_Pt_Impl
DEBUG INFO: DicosFsMo_Pt_Impl::systemStarted
-----> Built replica for mdp ( 1031891, 0 )
-----> Starting central process(es) in DU(s) with id=1045188
-----> Starting central process(es) in DU(s) with id=1048542
-----> Built replica for mdp ( 1018702, 0 )
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
-----> Starting central process(es) in DU(s) with id=1010520
-----> Database Global Coordinator started
 [OU/D139 R2B01] CentralQueryPort::start [1.1.3]:2b3809d0
-----> Built replica for mdp ( 1021810, 0 )
-----> Built replica for mdp ( 1031886, 0 )
-----> Built replica for mdp ( 1021806, 0 )
-----> Built replica for mdp ( 1031887, 0 )
-----> Built replica for mdp ( 1021808, 0 )
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
-----> Starting central process(es) in DU(s) with id=1011533
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
  :
  :
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: CwosNetRedVipPT_Impl.cc:322 [OU/D306 R1D01] NRV: Fail to get NetworkManagerClusterView, retrying...
LOG_ERR: DeeNewParty_Impl.cc:105 [SCC/MD44 R1D01] State transfer failed for process type [DicosDistributedIpManager] due to communication problems between the 'new' and the 'old' process instances. 
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
LOG_ERR: IPA: IPconfServerDialogue::timeoutForIpsSetup
--- End: Previous attempt 3 ---


--- Start: Previous attempt 2 ---
In CC log:
  "Starting Software Upgrade using Redundancy Reboot method".
     :
  "Software Upgrade succeeded"

Processor disable/enable order:
  1. Proc_m0_s11 (Linux)
  2. Proc_m0_s13 (Linux)
  3. Proc_m0_s09 (Dicos)
  4. Proc_m0_s01 (Dicos)
  5. Proc_m0_s05 (Dicos)
  6. Proc_m0_s15 (Dicos)
  7. Proc_m0_s17 (Dicos)
  8. Proc_m0_s19 (Dicos)
       :

When starting to reload Proc_m0_s19, the contact with the TelORB Manager (opened
from tos2) was lost.

- On IO1, check if there are any error dumps and/or crashcollector files:
    ls -l /opt/telorb/dumps/
    ls -l /opt/telorb/crashcollector/

- On e.g. tos2, start TelORB Manager and manually connect it to the system:
    source /ipims_dicos/BS2/tbWP073/Setup.csh
                                              (Including TSP4 RefApp and Extras)
    TelORBManager -alarms &            (Version ????? will be opened)
    Connect: 172.30.14.xx
--- End: Previous attempt 2 ---


--- Start: Previous attempt 1 ---
Alarm:
Processor Disabled            (Proc_m0_s11, 1.1.4, Linux TP)

Notifications:
System Upgrade Started
Backup Started                (Upgrade_step4...temp)
Backup Finished Successfully
Disable Processor Started     (Proc_m0_s11, 1.1.4)   ??!!
Disable Processor Succeeded
Backup Started                (Proc4__...)
Backup Finished Successfully
Enable Processor Started      (Proc_m0_s11, 1.1.4)
Enable Processor Failed       (1. Internal error)    ??!!

more /etc/tsp/eptftp.conf
--- Start printout ---
172.16.0.1 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s1/bootLoadTable.0 loadingGroup01_1
172.16.8.1 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s1/bootLoadTable.0 loadingGroup01_1
172.16.0.5 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s5/bootLoadTable.0 loadingGroup01_1
172.16.8.5 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s5/bootLoadTable.0 loadingGroup01_1
172.16.0.9 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s9/bootLoadTable.0 loadingGroup01_1
172.16.8.9 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s9/bootLoadTable.0 loadingGroup01_1
172.16.0.11 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s11/bootLoadTable.0 loadingGroup01_1
172.16.8.11 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s11/bootLoadTable.0 loadingGroup01_1
172.16.0.13 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s13/bootLoadTable.0 loadingGroup01_1
172.16.8.13 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s13/bootLoadTable.0 loadingGroup01_1
172.16.0.15 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s15/bootLoadTable.0 loadingGroup01_1
172.16.8.15 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s15/bootLoadTable.0 loadingGroup01_1
172.16.0.17 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s17/bootLoadTable.0 loadingGroup01_1
172.16.8.17 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s17/bootLoadTable.0 loadingGroup01_1
172.16.0.19 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s19/bootLoadTable.0 loadingGroup01_1
172.16.8.19 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s19/bootLoadTable.0 loadingGroup01_1
172.16.0.21 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s21/bootLoadTable.0 loadingGroup01_1
172.16.8.21 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s21/bootLoadTable.0 loadingGroup01_1
172.16.0.23 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s23/bootLoadTable.0 loadingGroup01_1
172.16.8.23 /opt/telorb/axe/loadingGroup01_1/Proc_m0_s23/bootLoadTable.0 loadingGroup01_1
172.16.0.137 /opt/telorb/axe/loadingGroup01_1/Proc_m1_s9/bootLoadTable.0 loadingGroup01_1
172.16.8.137 /opt/telorb/axe/loadingGroup01_1/Proc_m1_s9/bootLoadTable.0 loadingGroup01_1
--- End printout ---

Reactivated the backup for step 2 and then enabled Proc_m0_s11 => failed.
Enable Processor Started      (Proc_m0_s11, 1.1.4)
Enable Processor Failed       (6. Loading failure)    ??!!

Enabled Proc_m0_s11 and disconnected and reconnected it => failed.
Enable Processor Started      (Proc_m0_s11, 1.1.4)
Enable Processor Failed       (6. Loading failure)    ??!!

Performed a zone reload from the backup for step 2 => OK.

Applied the step 4 upgrade package again => failed. Same scenario as above.


Compared the upgrade package contents with to29 and only IDP/DEM101 stuff
differed:

telorb@Proc_m1_s1:/opt/telorb/axe/upgradePackages/step4/upgradeConfigurationData> diff upgradeControlData.02.sort  ../../to29_upgradepath_step4/upgradeConfigurationData/upgradeControlData.02.sort 
2c2
 // Thu Sep 22 09:30:16 2005 for telorb
---
 // Thu Sep 22 09:22:31 2005 for telorb
563a564,610
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/POT400:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO101:LM/AXG426:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO201:LM/AXG426:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO301:LM/AXG426:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO401:LM/AXG426:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO402:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO501:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO601:LM/AXG426:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO701:LM/AXG426:LM/D11
 IDPD:IDP/DEM101,CXP9010510/1:LMSA:LM/PRO801:LM/AXG426:LM/D11
 IDPD:IDP/DEM101:DUTA:De2CoDUT.SWI_PRO101:R1B99
 IDPD:IDP/DEM101:DUTA:De2CoPOT_DUT.OU_PRO101:R2A99
 IDPD:IDP/DEM101:DUTA:De2DisDUT.SWI_PRO301:R1B99
 IDPD:IDP/DEM101:DUTA:De2GWDUT.SWI_PRO601:R1A99
 IDPD:IDP/DEM101:DUTA:De2PopDUT.SWI_PRO501:R1B99
 IDPD:IDP/DEM101:DUTA:De2SubDUT.SWI_POT400:R1A99
 IDPD:IDP/DEM101:DUTA:De2SubLinuxDUT.SWI_PRO411:R1A99
 IDPD:IDP/DEM101:DUTA:De2TGDUT.SWI_PRO201:R1B99
 IDPD:IDP/DEM101:DUTA:De2UnixAccessDUT.SWI_PRO701:R1A99
 IDPD:IDP/DEM101:DUTA:De2VipAccessDUT.SWI_PRO801:R1A99
 IDPD:IDP/DEM101:IDPA:IDP/DEM101:R2C99:IDP/DEM101:Demo2.IDP_DEM101
 IDPD:IDP/DEM101:LMA:LM/POT400:R1B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2Subscriber.LM_POT400.Code.R1B99.i686,i686,48756,2029867021,1073130642
 IDPD:IDP/DEM101:LMA:LM/PRO101:R1D99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2Co.LM_PRO101.Code.R1D99.i686,i686,388800,-659083473,-905417105
 IDPD:IDP/DEM101:LMA:LM/PRO201:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2TG.LM_PRO201.Code.R2B99.i686,i686,73016,-1071473694,161469986
 IDPD:IDP/DEM101:LMA:LM/PRO301:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2Dis.LM_PRO301.Code.R2B99.i686,i686,91752,843929850,-956826042
 IDPD:IDP/DEM101:LMA:LM/PRO401:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2Sub.LM_PRO401.Code.R2B99.i686,i686,109672,-1885175051,1571982634
 IDPD:IDP/DEM101:LMA:LM/PRO402:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2SubJava.LM_PRO402.Code.R2B99.i686,i686,42872,-1325396338,-937402778
 IDPD:IDP/DEM101:LMA:LM/PRO411:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2SubLinux.LM_PRO411.Code.R2B99.i686,i686,19508,407883297,-303770912,codeArchive/Demo2.IDP_DEM101/De2SubLinux.LM_PRO411.Code.R2B99.i686-linux,i686-linux,47273,0,0
 IDPD:IDP/DEM101:LMA:LM/PRO412:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2SubJavaLinux.LM_PRO412.Code.R2B99.i686,i686,17340,-735460043,514639208,codeArchive/Demo2.IDP_DEM101/De2SubJavaLinux.LM_PRO412.Code.R2B99.i686-linux,i686-linux,17340,0,0
 IDPD:IDP/DEM101:LMA:LM/PRO501:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2Pop.LM_PRO501.Code.R2B99.i686,i686,91456,592844494,-806338704
 IDPD:IDP/DEM101:LMA:LM/PRO601:R1B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2Gw.LM_PRO601.Code.R1B99.i686,i686,61700,-799737846,-982539796
 IDPD:IDP/DEM101:LMA:LM/PRO701:R2B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2UnixAccess.LM_PRO701.Code.R2B99.i686,i686,68900,27323320,-984305031
 IDPD:IDP/DEM101:LMA:LM/PRO801:R1B99:IDP/DEM101:codeArchive/Demo2.IDP_DEM101/De2VipAccess.LM_PRO801.Code.R1B99.i686,i686,90936,137613043,1166678652
 IDPD:IDP/DEM101:POTA:De2CoPOT.OU_PRO101:R2A99
 IDPD:IDP/DEM101:POTA:ExtraServiceObject.SWI_POT400:R1A99
 IDPD:IDP/DEM101:POTA:Subscriber.SWI_POT400:R1A99
 IDPD:IDP/DEM101:PTA:De2CoPT.SWI_PRO101:R1B99
 IDPD:IDP/DEM101:PTA:De2DisPT.SWI_PRO301:R1B99
 IDPD:IDP/DEM101:PTA:De2GWPT.SWI_PRO601:R1A99
 IDPD:IDP/DEM101:PTA:De2PopPT.SWI_PRO501:R1B99
 IDPD:IDP/DEM101:PTA:De2SubPT.SWI_PRO401:R1B99
 IDPD:IDP/DEM101:PTA:De2SubPTJava.SWI_PRO402:R1B99
 IDPD:IDP/DEM101:PTA:De2SubPTJavaLinux.SWI_PRO412:R1A99
 IDPD:IDP/DEM101:PTA:De2SubPTLinux.SWI_PRO411:R1A99
 IDPD:IDP/DEM101:PTA:De2TGPT.SWI_PRO201:R1B99
 IDPD:IDP/DEM101:PTA:De2UnixAccessPT.SWI_PRO701:R1A99
 IDPD:IDP/DEM101:PTA:De2VipAccessPT.SWI_PRO801:R1A99

telorb@Proc_m1_s1:/opt/telorb/axe/loadingGroup01_1> more networkAddresses 
1 3 00:20:ce:c9:85:ba 00:20:ce:c9:85:bb
1 1 00:20:ce:c9:93:a2 00:20:ce:c9:93:a3
1 2 00:20:ce:c9:93:c6 00:20:ce:c9:93:c7
1 4 00:20:ce:c9:94:2e 00:20:ce:c9:94:2f
1 5 00:20:ce:c9:85:82 00:20:ce:c9:85:83
1 6 00:20:ce:c9:94:86 00:20:ce:c9:94:87
1 7 00:20:ce:c9:93:de 00:20:ce:c9:93:df
1 8 00:20:ce:c9:85:86 00:20:ce:c9:85:87
1 9 00:20:ce:c9:93:d6 00:20:ce:c9:93:d7
1 10 00:20:ce:c9:98:c2 00:20:ce:c9:98:c3
1 11 00:20:ce:c9:85:6e 00:20:ce:c9:85:6f
--- End: Previous attempt 1 ---


Step 5 - Smooth Upgrade
=======================

Since no generic upgrade packages for the upgrade path steps are currently
available, on e.g. CD/DVD, you have to build the upgrade package for this
step yourself.
These instructions, describe how to build upgrade packages on tos2.
To be able to access IO1 from tos2, a special mounting is required, which
has been done in the earlier upgrade path step ....


Build the upgrade for step 5
----------------------------
Step 5: It is enough to use tbWP051. Add TLMs separately below, if any.

The epct files for step 5 should be adjusted according to the following rules:

    * Remove the following software:

SOFTWARE IDP/D36;  // UDCRemoteServer

    * Add the following software:

SOFTWARE CXP9010516/1;        // AppTrace_IDP,        Application Trace support

    * Remove the following pool:

DicosUDCRemotePool (from all Dicos processors)

---
Include the LMs for step 5:

epconfig set -r <LMs for step 5>

---
Run epct with the updated epct files:
epct -d <destination directory> -v -F -c -u <config file for the system> <epct files>

The -X flag may be needed.


Step 6 - IO Upgrade
===================
    - Damn it! Just do it, Derek!        (Korn quotation)


Back to a step 2 (step 3) backup
================================
Clear the contents of the codeArchive directory:
  On any IO:
    cd /opt/telorb/axe/loadingGroup01_1
    (cp -r codeArchive codeArchive.old)
    cd codeArchive
    rm -rf *

Consider activeVersion and active link???
  Below ../backups:
    ln -s .. active

  Reset processors.

  Below ../backups:
    touch activeVersion


Initial load from step 2
========================
- Modify epct file, if not already done in the RM453 MCP3 phase:

  o To get step 4 to work, the NetRed IDP (IDP/D2) must be removed from the
    epct file. This also goes for the DicosNetRedPool and
    DicosNetRedConnectPool.
    Should this problem be fixed before release??!!
    Do as follows:
      - Remove:
        SOFTWARE IDP/D2;      // NetRed_IDP (Optional)
      - Remove:
        DicosNetRedPool and DicosNetRedConnectPool from all affected processors.

  o If the IO processors are already upgraded with step 3 and you want to
    initial load from step 2, some more changes are required in the epct file,
    i.e.:

    - Add:
      INITIAL_DATA
      InitialProcessor = "Proc_mX_sY"
      ENDDATA

    - Change mount points from /opt/telorb/axe to /opt/mirror:
FileSystemCommand_230 = "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc1 /loadingGroup01_1/ /opt/mirror/loadingGroup01_1"
FileSystemCommand_260 = "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.1.1 -o ipaddr=172.16.9.1 /dev/rpc2 /loadingGroup01_2/ /opt/mirror/loadingGroup01_2"
FileSystemCommand_290 = "mount -t nfs -o uid=101 -o gid=501 -o ipaddr=172.16.0.129 -o ipaddr=172.16.8.129 /dev/rpc3 /upgradePackages/ /opt/mirror/upgradePackages"

- Before building, clean up loadingGroups:
    On IO1:
    Delete all directories below loadingGroup01_1, except
    for the X...UNDI (???) directory before unpacking the loadingGroup.
    X...UNDI (???) must be kept:
      cd /opt/telorb/axe/loadingGroup01_1
      rm -rf backups/ codeArchive/ DicosEnvironment initialData/ java/ networkAddresses Proc* reconciliation/ tsp4*

    On IO2:
    Delete all directories below loadingGroup01_2, except
    for the X...UNDI (???) directory before unpacking the loadingGroup.
    X...UNDI (???) must be kept:
      cd /opt/telorb/axe/loadingGroup01_2
      rm -rf backups/ codeArchive/ DicosEnvironment initialData/ java/ networkAddresses Proc* reconciliation/ tsp4*

- Add TLMs:
    2 epconfig s -r uabnasl... Ask Stefan first...

Use the epct file to build the system.

Below ../backups:
  ln -s .. active

Reset processors.

Below ../backups:
  touch activeVersion

Create a backup.


Build TSP 4 upgrade packages for testing purposes
=================================================

Build upgrade package for DicosKernel_LM to test redundancy upgrade after step 2
================================================================================

Build new LM DicosKernel.LM_AXG561
----------------------------------
Open a new shell to build a new LM DicosKernel.LM_AXG561 from and enter
the following:
  ssh -X telorb@tos2
  Password: tsP4ever

  cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/upgradePackages_for_testing
  Remove any existing DicosKernel_LM directory

  mkdir epws  (If not already done)

  setenv EP_WORKSPACE `pwd`/epws

  source /ipims_dicos/BS2/tbAD14l_4to5_redundancyPrep/IP_CONF_INFO/EnvSettings

Check out:
  epgetpath LM/AXG561
  epsi co -r R4C11 LM/AXG561
Add "test" to version:
  cd DicosKernel_LM/
  emacs MI_attributes &
Build:
  cd ..
  epconfig s DicosKernel_LM/
  epbuild -T i486 DicosKernel_LM/
Compare sizes (should be the same):
  ls -l /ipims_dicos/ipims_dicos20/BS2/tbAD14l_4to5_redundancyPrep/DICOS_IDPG/Dicos_IDP/DicosKernel_LM/bin/
  ls -l DicosKernel_LM/bin/


Build upgrade package
---------------------
cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3
Create a .config file, using the TelORB Manager.
source /ipims_dicos/BS2/tbAD14l_4to5_redundancyPrep/IP_CONF_INFO/EnvSettings

(Use other location next time, e.g. dicostest:)
cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3

(Use other location next time, e.g. dicostest:)
Copy the previously created .config file from IO1 to tos2:
  scp telorb@toXXio1:/opt/telorb/axe/loadingGroup01_1/step2.config . 
  Password: tel123orb

cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3
source /ipims_dicos/BS2/tbAD14l_4to5_redundancyPrep/IP_CONF_INFO/EnvSettings
Create a name file and insert the NAME line:
emacs name_DicosKernel_R4C11test&
  NAME DicosKernel_R4C11test;

epconfig s -r /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/upgradePackages_for_testing/DicosKernel_LM/

Check if there are any TLMs to be used:
  ls -l /home/dicoshack/Hack/WP051/step4/

    If there are TLMs, then:
      epconfig set -r /home/dicoshack/Hack/WP051/step4/

Add other TLMs, if any:
  epconfig set -r ...

(Or use the copied .config file from IO1:)
epct -v -F -X -u /home/dicostest/tosFiles/to14/upgradepath/step2/step2.config name_DicosKernel_R4C11test r14_linux_nsp5_maxi_zone1_to14_midi.epct r14_linux_refapp_to14.epct r14_linux_vip_to14.epct r14_linux_extra_config_to14.epct

--- Start: Example printout ---
 Upgrade method: DicosRedundancyReboot caused by LM/AXG561 
 The generated upgrade package DicosKernel_R4C11test consists of :

      changed LM: LM/AXG561 (R4C11 -> R4C11test)
      changed DUT(s): DicosKernel_DUT.LM_AXG561 
--- End: Example printout ---

  more /home/dicostest/tosFiles/to14/upgradepath/step4/upgradePackages/DicosKernel_R4C11test/upgradeConfigurationData/upgradeControlData.01
  more /home/dicostest/tosFiles/to14/upgradepath/step4/upgradePackages/DicosKernel_R4C11test/upgradeConfigurationData/upgradeControlData.02

Modify the format (only valid if the system is currently in step 2):
  cd DicosKernel_R4C11test/upgradeConfigurationData/
  emacs upgradeControlData.02&
Copy ":IDP/MD14" to before "codeArchive", i.e.:
  From:
IDPD:IDP/MD14:LMA:LM/AXG561:R4C11test:codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R4C11test.i486,i486,1845236,987408447,-295230564
IDPD:IDP/MD14:DUTA:DicosKernel_DUT.LM_AXG561:R4C11test

  To:
IDPD:IDP/MD14:LMA:LM/AXG561:R4C11test:IDP/MD14:codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R4C11test.i486,i486,1845236,987408447,-295230564
IDPD:IDP/MD14:DUTA:DicosKernel_DUT.LM_AXG561:R4C11test


(  cd /home/dicostest/tosFiles/to14/upgradepath/step4  )
(  ls -l
  The file "step4.config" and the directory "upgradePackages" should have been
  created.  )


Pack and upload the upgrade package to IO1
------------------------------------------
On tos2:
  cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3/upgradePackages
  tar zcf DicosKernel_R4C11test.tgz DicosKernel_R4C11test
  scp DicosKernel_R4C11test.tgz telorb@toXXio1:/opt/telorb/axe/upgradePackages
  Password: tel123orb  (Adjust toXX to valid TSP system)


Unpack the upgrade package on IO1
---------------------------------
On IO1:
  cd /opt/telorb/axe/upgradePackages
  tar zxf DicosKernel_R4C11test.tgz


Apply upgrade package "DicosKernel_R4C11test"
---------------------------------------------
In TelORB Manager's "Upgrades" card, click "Rescan" and then select
"DicosKernel_R4C11test" and click "Apply".


*** Shortcut instructions for the same thing ***

Build new LM DicosKernel.LM_AXG561
----------------------------------
ssh -X telorb@tos2
cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/upgradePackages_for_testing
mkdir epws
setenv EP_WORKSPACE `pwd`/epws
source /ipims_dicos/BS2/tbAD14l_4to5_redundancyPrep/IP_CONF_INFO/EnvSettings
epgetpath LM/AXG561
epsi co -r R4C11 LM/AXG561
cd DicosKernel_LM/
emacs MI_attributes &
cd ..
epconfig s DicosKernel_LM/
epbuild -T i486 DicosKernel_LM/
ls -l /ipims_dicos/ipims_dicos20/BS2/tbAD14l_4to5_redundancyPrep/DICOS_IDPG/Dicos_IDP/DicosKernel_LM/bin/
ls -l DicosKernel_LM/bin/

Build upgrade package
---------------------
cd /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/initialstart_to14_rm453_ec3
source /ipims_dicos/BS2/tbAD14l_4to5_redundancyPrep/IP_CONF_INFO/EnvSettings
epconfig s -r /home/dicoshack/Hack/uabmsu/upgradepath_tsp4to5/upgradePackages_for_testing/DicosKernel_LM/
Create a name file and insert the NAME line:
emacs name_DicosKernel_R4C11test&
  NAME DicosKernel_R4C11test;

epct -v -F -X -u /home/dicostest/tosFiles/to14/upgradepath/step2/step2.config name_DicosKernel_R4C11test r14_linux_nsp5_maxi_zone1_to14_midi.epct r14_linux_refapp_to14.epct r14_linux_vip_to14.epct r14_linux_extra_config_to14.epct
Result printout:
 Upgrade method: DicosRedundancyReboot caused by LM/AXG561 
 The generated upgrade package DicosKernel_R4C11test consists of :

      changed LM: LM/AXG561 (R4C11 -> R4C11test)
      changed DUT(s): DicosKernel_DUT.LM_AXG561 

Modify the format (only valid if the system is currently in step 2):
  cd DicosKernel_R4C11test/upgradeConfigurationData/
  emacs upgradeControlData.02&
Copy ":IDP/MD14" to before "codeArchive", i.e.:
  From:
IDPD:IDP/MD14:LMA:LM/AXG561:R4C11test:codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R4C11test.i486,i486,1845236,987408447,-295230564
IDPD:IDP/MD14:DUTA:DicosKernel_DUT.LM_AXG561:R4C11test

  To:
IDPD:IDP/MD14:LMA:LM/AXG561:R4C11test:IDP/MD14:codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R4C11test.i486,i486,1845236,987408447,-295230564
IDPD:IDP/MD14:DUTA:DicosKernel_DUT.LM_AXG561:R4C11test

Go to the following link to get a
script for automatic set up of controlling environment.

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions (Adjust toX to valid TelORB system name in the command lines below.) From a local shell: xhost + cmdtool -Wl toXLogs & (Open window for TelORB processor log files/consoles) ssh telorb@toXio1 or (In opened window) (If Linux IO) telnet -l telorb toXio1 (In opened window) (If UNIX IO) cd /opt/telorb/consolelogs/ (In opened window) cmdtool -Wl tos1 & (Open window for build environment at the EAB CW/OS lab) ssh telorb@tos1 (In opened window) cd /home/dicostest/tosFiles/toX/ (In opened window) (Adjust toX to valid TelORB system) cmdtool -Wl tos2 & (Open window for build environment at the EAB CW/OS lab) ssh telorb@tos2 (In opened window) cd /home/dicostest/tosFiles/toX/ (In opened window) (Adjust toX to valid TelORB system) cmdtool -Wl toXio1 & (Open window for IO processor 1 (IO1)) ssh telorb@toXio1 or (In opened window) (If Linux IO) telnet -l telorb toXio1 (In opened window) (If UNIX IO) cmdtool -Wl toXio2 & (Open window for IO processor 2 (IO2)) ssh telorb@toXio2 or (In opened window) (If Linux IO) telnet -l telorb toXio2 (In opened window) (If UNIX IO) cmdtool -Wl toXio1crash & (Open window for error dumps on IO 1) ssh telorb@toXio1 or (In opened window) (If Linux IO) telnet -l telorb toXio1 (In opened window) (If UNIX IO) cd /opt/telorb/crashcollector/ or (In opened window) cd /opt/telorb/dumps/ (In opened window) cmdtool -Wl toXio2crash & (Open window for error dumps on IO2) ssh telorb@toXio2 or (In opened window) (If Linux IO) telnet -l telorb toXio2 (In opened window) (If UNIX IO) cd /opt/telorb/crashcollector/ or (In opened window) cd /opt/telorb/dumps/ (In opened window) (cmdtool -Wl toXCons & (Open window for TelORB processor consoles) cd /home/telorb/labSystems/targetSystems/toX/consolelogs/ (In opened window))

General
The instructions in this section are valid for a single TelORB system.
Note that some of the instructions in this section have become outdated.

Step 1: Open new shell windows and name them

- Open a shell window from a WS that is connected to the Pink LAN network
  (i.e. 134.138.186 and 134.138.187).
- From the opened shell window, open new shell windows and name them as
  described below (other names may of course be used):

    xhost +                      (If not already entered)
    cmdtool -Wl toXLogs &        (Open control window, on IO processor, for
                                  TelORB processor log files)
    cmdtool -Wl toXCons &        (Open control window, locally, for TelORB
                                  processor consoles to capture printouts)
    cmdtool -Wl tos1 &           (Open control window for tos1. Either use tos1
                                  or tos2. See section above for explanation)
    cmdtool -Wl toXio1 &         (Open control window for IO processor 1. Adjust
                                  toX to valid TelORB system)
    cmdtool -Wl toXio2 &         (Open control window for IO processor 2. Adjust
                                  toX to valid TelORB system)

  For further information about TelORB processor log files and consoles, see
  Start TelORB processor log files and consoles.
 
- Iconize or quit the window from where the new shell windows were opened, if
  desired.


Step 2: Go to the correct locations in each of the opened windows

- In window toXLogs:
    telnet toXio1                     (Log in to IO processor 1. Adjust toX to
                                       valid TelORB system or use IP address)
    login: telorb                     (Type user name)
    Password:                         (Type password)

    cd /opt/telorb/consolelogs/       (If this directory does not exist, create
                                       it. For further info, see STS)
    Iconize the window, if desired.


- In window toXCons:
    cd /home/telorb/labSystems/targetSystems/toX/consolelogs/  (Adjust toX to
                                                                valid TelORB
                                                                system)
    Iconize the window, if desired.


- In window tos1:
    telnet tos1                       (Log in to the alpha machine tos1 or tos2)
    login: telorb                     (Type user name)
    Password:                         (Type password)

    cd /home/dicostest/tosFiles/toX/  (Adjust toX to valid TelORB system)
    If the build environment is elsewhere, go there, e.g.:
    cd ad12.4/                        (Go to the directory where all the build
                                       (epct) files are located. Adjust ad12.4
                                        to valid directory)
    (mkdir epws                       (If the directory epws does not exist in
                                       the build environment, create it.
                                       If epct files do not exist, copy them
                                       from another location and adjust them
                                       to suit your TelORB release))
    Iconize the window, if desired.


- In window toXio1:
    telnet toXio1                     (Log in to IO processor 1. Adjust toX to
                                       valid TelORB system or use IP address)
    login: telorb                     (Type user name)
    Password:                         (Type password)

    Iconize the window, if desired.


- In window toXio2:
    telnet toXio2                     (Log in to IO processor 2. Adjust toX to
                                       valid TelORB system or use IP address)
    login: telorb                     (Type user name)
    Password:                         (Type password)

    Iconize the window, if desired.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
Instead of using telnet when connecting, it is possible to use rlogin (except
when logging in to the IO processors, where rlogin is barred from R13 and
higher).
When using rlogin, be sure to set the environment variable DISPLAY to the IP
address of the WS to display on.
An example:
    rlogin tos1                       (Remotely log in to the alpha machine
                                       tos1 or tos2)
    psw                               (Type password)
    setenv DISPLAY 134.138.186.xx:0.0 (Set IP address of the WS to display on.
                                       Adjust the IP address to the WS that you
                                       are working on)

To exit from a telnet session, just give command "exit".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Script for automatic set up of controlling environment
 (Updated: 2002-01-17)

The script /home/telorb/startAll performs the following:
- Starts TelORB processor consoles towards the TelORB system which is specified
  when starting the script.
- Creates two shells and logs in to the two valid IO processors (IO1 and IO2).
- Starts the TelORB Manager.
- Logs in to tos1 and goes to the directory which belongs to the specified
  system.

Limitations:
- The script currently does not work towards TSP 4 systems, i.e. the script
  can only be used for the following TelORB systems:
    to7, to8 to14, to15, to20, to21, to22 and to23

To start the script, do as follows:
  cd /home/telorb/
  ./startAll toX                             (Adjust toX to valid TelORB system)

(Script created by uabadp, 2001-01-16)

General
This section is not updated for TelORB R14 and is not completely valid for
TelORB R13. (When upgrading to TelORB R13, it is a good advice to save the
present plLoadable file before running the tools script, for fallback reasons.)

Before initial loading a TelORB system, it is important that the versions of the
  - TelORB processor hardware files
  - IO tools package
  - start_services file
correspond to the TelORB release to be loaded.
Of course, other items are also important to verify, but what is mentioned here
is just what people constantly seem to forget.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 1: Verify TelORB processor hardware files
This section requires updating!

- The TelORB processor boards should have the PROM version that corresponds to
  the TelORB release to be loaded.
  Verify this by using the TelORB Manager/Browser (only valid if the TelORB
  system is up and running) or by using a terminal server.
  (To start a TelORB Manager/Browser, see section
  Start TelORB Manager/Browser and alarm & notification window in these
  guidelines.)

- If small PROM is used (see Fetch PROM firmware for further information about
  small PROM), a pointer should be set to the valid plLoadable file which
  corresponds to the TelORB release to be loaded.
  Upto and including AD 9.05.3, the file /tftpboot/telorb/ppro/dhcptab should be
  used. (Actually /var/dhcp/dhcptab?)
  From AD12 and higher, the file /opt/telorb/etc/dhcpd.pxe.conf should be used.

    If the dhcpd.pxe.conf file is used, verify that the correct pointer is set
    on both IO processors:
      cd /opt/telorb/etc/
      ls -l
      more dhcpd.pxe.conf
      Verify that the file dhcpd.pxe.conf points to the correct plLoadable file,
      i.e. the file should contain a line like the following:
        filename "telorb/ppro/plLoadable";

      Verify that the valid plLoadable file is used:
        cd /tftpboot/telorb/ppro/
        ls -l

    If the dhcptab file is used, verify that the correct pointer (link) is set
    in both IO processors:
      cd /tftpboot/telorb/ppro/
      ls -l                      (Example: plLoadable -> plLoadable_AD9.05.3)
      (more dhcptab)

For further information about verification of the TelORB processor hardware,
consult the section Verify PROM firmware in these guidelines.
To get information about e.g. how to change the plLoadable file, consult section
Fetch PROM firmware in these guidelines.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 2: Verify that the correct IO TelorbServices file is being used on both IO processors
This section requires updating!

  Upto and including AD12, the file S15TelorbServices should be used.
  From AD13, the file S88TelorbServices should be used.

  The file(s) exist at /etc/rc3.d/ on the IO processors.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 3: Verify that the correct Kickstart version is installed on both IO processors
Check Kickstart version on both IOs:
  more /etc/version

Example for TSP 4.0:
  KickStart-Name: ks-io-hdc.cfg
  KickStart-PN:   ii1OU/D203
  KickStart-Rev:  R1B20
  IOprocessor-ID: io1

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 4: Verify that the correct RedHat Linux version is installed on both IO processors
Check RedHat version on both IOs:
  more /etc/redhat-release

Example for TSP 4.0:
  Red Hat Linux release 7.1 (Seawolf)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 5: Verify that the correct version of the IO tools package is installed on the IO processors
- The IO tools package that is installed on the IO processors, must correspond
  to the TelORB release to be loaded.
  Verify this on both IO processors by checking the version that is specified in
  the IDP_MD15-Unix/MI_attributes file as follows:
    more /opt/telorb/tools/IDP_MD15-Unix/MI_attributes
    (or more /toX/toXio1/telorb/tools/IDP_MD15-Unix/MI_attributes from tos1/tos2)
  (Look for e.g. <Version>R1B21</Version>).

  The versions for different ADs are specified in the section
  Versions of TelORB IO software (tools), where also further information about
  the IO tools package may be found for releases lower than TelORB R13.
  (However, some versions may have been changed by patches.)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 6: Verify the settings in the start_services files
Prerequisite: The correct version of the IO tools package is installed.

- The start_services file that is (will be) running on the IO processors, must
  correspond to the TelORB release to be loaded.
  Verify this on both IO processors by checking that the contents of each
  start_services file (below directory /opt/telorb/etc/) corresponds to the
  io1.start_services and io2.start_services templates, respectively:
    - Compare the following files on IO1:
        more /opt/telorb/etc/start_services 
        more /opt/telorb/tools/etc/io1.start_services

    - Compare the following files on IO2:
        more /opt/telorb/etc/start_services 
        more /opt/telorb/tools/etc/io2.start_services

  If there are any differencies, modify the start_services file so that it
  corresponds to its corresponding ioY.start_services file. (Adjust ioY to valid
                                                             IO processor)

Step 1: Modify TelORB and IO set up files, if necessary
Modification of the TelORB system building files and/or IO processor files may
be necessary if e.g. some changes have been made to the TelORB system since the
last time it was initially loaded (e.g. new TelORB release, swapped or new
TelORB processor boards and/or IO processor boards).

Examples of TelORB system building files and IO processor files can be found at
TelORB and IO set up files for..., click on the AD release of interest, and then
select "General file information".

For TSP 4 the following applies at the EAB CW/OS lab
----------------------------------------------------
set Owndir=`pwd`
cd /home/dicostest/systest/tsp4.0/TelORB-R14-Linux-upto-patch4/TelORB-R14-Linux-Runtime3.4/
source setup.csh
epconfig d -a 
epconfig use APR/901268/3 R1A05       (R1A05 for patch 3, see explanation below)
cd /home/dicostest/systest/tsp4.0/TelORB-R14-Linux-upto-patch4/TelORB-R14-Linux-SDK3.4
source setup.csh
echo "Using TelORB Clusterware/OS APR/901268/3 `epgetattr Version APR/901268/3`"
echo "Using TelORB Clusterware/OS APIs CRA/119741/1 `epgetattr Version CRA/119741/1`"
echo "Using TelORB Clusterware/OS SDK CRA/119760/1 `epgetattr Version CRA/119760/1`"
echo "Using TelORB Clusterware/OS Vega CRA/119761/1 `epgetattr Version CRA/119761/1`"
cd $Owndir

Select a different version than the latest:
  epconfig use APR/901268/3 R1A01  (EarlyDrop 3.4 PRA)
  epconfig use APR/901268/3 R1A02  (Patch 1)
  epconfig use APR/901268/3 R1A03  (Patch 2)
  epconfig use APR/901268/3 R1A05  (Patch 3)
  epconfig use APR/901268/3 R1A07  (Patch 4)
  epconfig use APR/901268/3 R1B05  (Patch 5)   (R1U02 tools)
  epconfig use APR/901268/3 R1B06  (Patch 5.1) (R1A14 in Delivery Note) (Tools not changed)
  Patch 5.2 is not installed, since it only contains SDK.
  epconfig use APR/901268/3 R1B08  (Patch 5.3) (Tools not changed)
  epconfig use APR/901268/3 R1B09  (Patch 5.4) (Tools not changed)
  epconfig use APR/901268/3 R1B10  (Patch 5.5) (Cancelled)
  epconfig use APR/901268/3 R1B11  (Patch 5.6) (Tools not changed)
  epconfig use APR/901268/3 R1B12  (Patch 5.7) (Tools not changed)
  epconfig use APR/901268/3 R1B13  (Patch 5.8) (Cancelled)
  epconfig use APR/901268/3 R1B15  (Patch 5.9) (Previously R1B14) (R1U06 tools)
  epconfig use APR/901268/3 R2A02  (Patch 6)   (Cancelled)
  epconfig use APR/901268/3 R2B03  (Patch 7)   (R1Z02 tools)
  epconfig use APR/901268/3 R2B04  (Patch 7.1) (Tools not changed)
  epconfig use APR/901268/3 R3A03  (Patch 7.2) (Tools not changed (error in
                                                Delivery Note))
  epconfig use APR/901268/3 R3A04  (Patch 7.3) (Tools not changed)
  epconfig use APR/901268/3 R3A05  (Patch 7.4) (Tools not changed) (Magnus test)
  epconfig use APR/901268/3 R3A06  (Patch 7.5) (Tools not changed) (Michel test)
  epconfig use APR/901268/3 R3A07  (Patch 7.6) (Tools not changed) (Peder test)
  epconfig use APR/901268/3 R3A08  (Patch 7.7) (Tools not changed) (Andreas test)
  epconfig use APR/901268/3 R3A09  (Patch 7.8) (Tools not changed) (Andreas test)
  epconfig use APR/901268/3 R3A10  (Patch 7.9) (R1Z03 tools) (Andreas test)
  epconfig use APR/901268/3 R3A11  (Patch 7.10) (Tools not changed) (John test)
  epconfig use APR/901268/3 R3B01  (Patch 8)   (R1AC02 tools) (Michel test)
                                               (Revision G of the template files
                                                is missing in the environment
                                                /home/dicostest/systest/tsp4.0/
                                                for patch 8 due to a building
                                                failure at Integration.)

Read current version:
  epgetattr Version APR/901268/3

(To check which patch versions (on APR level) that are already installed, type:
   ls -l /home/dicostest/systest/tsp4.0/TelORB-R14-Linux-upto-patchXX/TelORB-R14-Linux-Runtime3.4/system/TelORB/
     (Adjust patchXX to valid patch level)

epct debug settings
-------------------
# Enable DBN LinuxDriver Trace (result can be found in /var/log/syslog):
Ddb_minorTrace = (900)

# Sverker Ericsson's debug (result can be found in /var/log/syslog):
Ddb_majorTrace = (235)
IpcPortTableSize = "20000"


Step 2: Specify which SW to load
The basic TelORB software is fetched from the location specified in the
Envsettings file.
To load e.g. TelORB AD9.05.3 upto and including patch 3, the following should be
specified in the Envsettings file:
  Fetch software from distribution:
      :
    cd /ipims_dicos/ipims_dicos10/dists/TelORB-AD9.05.3/
    source setup.csh
      :
    epconfig d -a
    epconfig s -r /ipims_dicos/ipims_dicos10/dists/AD9.05-patch/official/patch1/
    epconfig s -r /ipims_dicos/ipims_dicos10/dists/AD9.05-patch/official/patch2/
    epconfig s -r /ipims_dicos/ipims_dicos10/dists/AD9.05-patch/official/patch3/

  Note that it is only possible to source a distribution for clean RMs.
  
  Fetch software from testbed:
      :
    source /ipims_dicos/BS2/tbAD9.05p3/IP_CONF_INFO/EnvSettings

Optional software is specified as follows:

  Preferably, use the previously opened shell window
  named "tos1" or "tos2" and go to the directory where the build
  environment is located, e.g. /home/dicostest/tosFiles/toX/ad12.4/ and then
  enter the following (Adjust toX to valid TelORB system.):

    more Envsettings                (Verify that the file Envsettings contains
                                     correct data, i.e. which TelORB release to
                                     fetch software from and which epct files to
                                     use)
    source Envsettings              (Source the Envsettings file)
    epconfig l -v                   (Check if there are any settings to override
                                     where to load load modules from)
    Optional:
      epconfig d -a                 (If desired, delete all epconfig settings)
      epconfig s ...                (If desired, fetch one or several load
         (See include-lines below)   modules from a different place than what is
                                     specified in the Envsettings file.
                                     "epconfig s ..." will replace the same load
                                     modules that are linked to in the
                                     Envsettings file or they are added to the
                                     load modules that are linked to in the
                                     Envsettings file.)

  The following SW and applications are optional:

  Include Knuerr (HW alarm application):
  No epconfig settings required, since the SW is included in ADs and TBs.
  However, the epct file must include Knuerr SW settings.

  Include AXmp (SS7):
  No epconfig settings required, since the SW is included in ADs and TBs.
  However, the epct file must include AXmp SW settings.

  Include DemoApp 2000 (C++ and java traffic application):
  No epconfig settings required, since the SW is included in tbTEST.
  Source correct version of tbTEST (see "Source EAB CW/OS lab test applications"
  below).
  The epct file must include DemoApp 2000 SW settings.

  Include DemoApp (C++ traffic application):
  No epconfig settings required, since the SW is included in tbTEST.
  Source correct version of tbTEST (see "Source EAB CW/OS lab test applications"
  below).
  The epct file must include DemoApp SW settings.

  Include JavaApp (Java (and C++) traffic application):
  No epconfig settings required, since the SW is included in tbTEST.
  Source correct version of tbTEST (see "Source EAB CW/OS lab test applications"
  below).
  The epct file must include JavaApp SW settings.

  Note: For AD9.05.3, an epconfig setting is required as follows:
  epconfig s -r /ipims_dicos/ipims_dicos20/BS2/tbAD9.05/TEST_IDPG/JavaDemo_IDP/

  Include DOI and Java DPI (For testing of Database Object Interface and Java DPI):
  Set epconfig according to instructions in DOI and Java DPI tests.

  Include OmedApp (Traffic application that generates overload):
  Adjust tbAD12 in the epconfig command below to valid (corresponding) testbed.
  The SW is not included in ADs. The epct file must include OmedApp SW settings.
   
  epconfig s -r /ipims_dicos/ipims_dicos20/BS2/tbAD12/TEST_IDPG/Omed_IDP/

  Include Jambala 2.0, i.e. HLR, AC and SCP, and the populator (Valid for AD9.05, AD11.4.1, AD12 and R13):
  The SW is not included in ADs. The epct file must include Jambala 2.0 SW settings.

  HLR & AC:  epconfig s -r /home/dicostest/systest/Applications/JAMBALA2.0/APPLICATION/Hlr_SA_J2.0D14_OS9.04_i486/
  SCP:	     epconfig s -r /home/dicostest/systest/Applications/JAMBALA2.0/APPLICATION/Scp_SA_J2.0_D5_OS9.04.i486/
  Populator: epconfig s -r /home/dicostest/systest/Applications/JAMBALA2.0/APPLICATION/Populator/

  Include a patch package:
  Adjust AD12.4-patch/official/patch1 in the epconfig command below to valid AD
  and patch.

  epconfig s -r /ipims_dicos/ipims_dicos10/dists/AD12.4-patch/official/patch1/

  Include an LM from a designer, e.g. from uablhl:
  epconfig s -r  /home/dicoshack/Hack/uablhl/home/uablhl/work/tb38.6/LoadingDriver_LM/


Source EAB CW/OS lab test applications (optional)

     TelORB release R15 (TSP 5.0)
       source /ipims_dicos/BS2/tbTEST1.4/IP_CONF_INFO/EnvSettings

     TelORB release R14 (JAP 3) & R14-Linux (TSP 4.0):
       source /ipims_dicos/BS2/tbTEST1.3/IP_CONF_INFO/EnvSettings

     TelORB release R13:
       source /ipims_dicos/BS2/tbTEST1.2/IP_CONF_INFO/EnvSettings

     TelORB release AD12.4:
       source /ipims_dicos/BS2/tbTEST1.1/IP_CONF_INFO/EnvSettings

     TelORB release AD9.05:
       source /ipims_dicos/BS2/tbTEST1.0/IP_CONF_INFO/EnvSettings

Hints
- Check all sourcings:
    echo $EP_CONFIGPATH | tr : '\n'   (tr : '\n' replaces colon with line brake)

- Check all epconfig settings, except e.g. settings for JAMBALA2.0:
    epconfig l -v | grep -v JAMBALA2.0
- Check all epconfig settings fetched from e.g. patch2:
    epconfig l -v | grep patch2
- Check all epconfig settings fetched from the designer uablhl:
    epconfig l -v | grep uablhl


Step 3: Build the TelORB system
Warning! Note that in the EAB CW/OS lab environment, when using tos1/tos2,
all current backup versions (if any), among other things, that are stored on
the IO processors, that belong to the TelORB system, will be erased when using
the build command epct below. This implies that if the build command epct is
executed, the current TelORB system that is up and running (if any) cannot be
reloaded, only initially loaded which probably is the case since you are
following these instructions.
If desired, save the loading groups (/opt/telorb/axe/loadingGroup01_x/)
elsewhere.

If it is suspected that the release (to use at initial load) contains one or
several LMs that have the same versions as their respective LMs in the directory
/opt/telorb/axe/loadingGroup01_x/codeArchive/ and that these LMs are modified,
it is best to remove the codeArchive directory (or the contents of the
loadingGroup01_x directory or even the complete axe directory, to clean
everything up). The reason for this is that the directory
/opt/telorb/axe/loadingGroup01_x/codeArchive/ is not being erased when building,
it is just being updated and if the version of an LM already exists, it will not
be overwritten which means that the "old" version of the LM will be used. (This
is however not always the case.) Do as follows to prevent this from happening
and to be on the safe side:

On IO processor 1:
  cd /opt/telorb/axe/loadingGroup01_1/
  rm -r codeArchive/                (Remove the codeArchive directory)
    or
  rm -rf *                          (Remove the contents of the loadingGroup01_1
                                     directory)

On IO processor 2:
  cd /opt/telorb/axe/loadingGroup01_2/
  rm -r codeArchive/                (Remove the codeArchive directory)
    or
  rm -rf *                          (Remove the contents of the loadingGroup01_2
                                     directory)

To be able to "build", the directories /opt/telorb/axe/loadingGroup01_1/ and
/opt/telorb/axe/loadingGroup01_2/ (user telorb) must exist on IO1 and IO2,
respectively. If the directories do not exist, create them by using the mkdir
command.

Use "which epct" before running epct to verify that the correct version of epct
will be invoked.

Use the valid alias command that is specified in the file Envsettings in the
build directory (e.g. /home/dicostest/tosFiles/toX/ad12.4/):

alias build...                 (Check that build... contains correct build data)

build...                       (Build the system using the valid alias)
  or use the epct command directly as specified in the examples below:

  Either (for splitted epct files)
    epct -t i486 -vFc -f loadingGroup01_1 -f loadingGroup01_2 -d ../axe name_netred.epct telorb.epct ../../epct/ad13/telorbDataGeneral.epct telorbDataLocal.epct processor.epct netred.epct demo.epct java.epct omed.epct servicePlatform.epct pools.epct
          (../axe = e.g. /home/dicostest/tosFiles/toX/axe)
          (../../epct/ad13/telorbDataGeneral.epct = /home/dicostest/tosFiles/epct/ad13/telorbDataGeneral.epct)
  or (for combined epct file)
    epct -t i486 -vFc -f loadingGroup01_1 -f loadingGroup01_2 -d ~/toX/axe toX.epct
          (~/toX/axe = e.g. /home/dicostest/tosFiles/toX/axe)
  (Adjust toX to valid TelORB system)

Hints
-----
- For splitted epct files, make sure that processor.epct is specified after
  telorb.epct, i.e. a good order of specifying the epct files is as follows:
  telorb.epct telorbData.epct processor.epct ...

- Make sure that a directory, named epws, exists in the build environment, e.g.
  below /home/dicostest/tosFiles/toX/ad12.4/. If not, the ep-commands will not
  work - just create the directory by entering:
    mkdir epws

- It is possible to build using only one IO processor, e.g. IO1; in this case
  just remove "-f loadingGroup01_2" from the epct command.

- If "source Envsettings" results in "exec: perl5: not found" on e.g. TelORB
  system toX (Adjust toX to valid TelORB system.):
    tos1:toX>source Envsettings      (NOK)
    exec: perl5: not found
    Exit 127
    tos1:toX>su
    tos1:toX#cd /bin
    tos1:/bin#ls -l per*
    tos1:/bin#which perl
    /usr/bin/perl
    tos1:/bin#cd /usr/bin/
    tos1:bin#ls -l per*
    perl*        perl5.00404* perldoc*     
    tos1:bin#ln -s perl5.00404 perl5
    tos1:bin#exit
    exit            (Exit su mode)
    tos1:toX>source Envsettings      (OK)


- If the epct-command results in the error messages
  ".../bin_alpha/perl5: cannot execute binary file
  .../bin_alpha/perl5: Exec format error"
  there is probably a fault in the software production.
  Call uabhha and ask her to fix it.


- If the epct-command results in the error messages
  "epgetpath: Command not found.
  /bin/Ldu.LM_MD43.R1B03.alpha-linux: Command not found.
  epct: ERROR, ldu failed
  Exit 1"
  execute the following commands (taken from the file Envsettings), but change
  the AD number for a different AD number and then source the original
  Envsettings file again, as follows:
    set Owndir=`pwd`
    cd /ipims_dicos/ipims_dicos10/dists/TelORB-AD7.51/
    source setup.csh
    Go to where the Envsettings file is.
    source Envsettings                        (source original Envsettings file)

- If a testbed is used (not an AD), perform the corresponding sequence for the
  testbed part in the file Envsettings.

- If you want to run a TelORB system with only one IO processor, follow the
  steps mentioned in Usage of only one IO processor.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Build without using the EAB CW/OS lab specific tos1/tos2 machine mountings
 (Updated: 2003-07-03)

- Build on e.g. tos1/tos2 as specified above.
- cd ../axe/       (Go to the directory where the loadingGroups have been built)
- tar cf loadingGroup01_1.tar loadingGroup01_1
- tar cf loadingGroup01_2.tar loadingGroup01_2
- On IO1:
    cd /opt/telorb/axe/
    mv loadingGroup01_1 loadingGroup01_1.old
- On IO2:
    cd /opt/telorb/axe/
    mv loadingGroup01_2 loadingGroup01_2.old
- Copy loadingGroup01_1.tar to directory /opt/telorb/axe/ on IO1 using e.g. ftp.
- Copy loadingGroup01_2.tar to directory /opt/telorb/axe/ on IO2 using e.g. ftp.
- On IO1:
    tar xf loadingGroup01_1.tar
- On IO2:
    tar xf loadingGroup01_2.tar

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions (Adjust toX to valid TelORB system name in the command lines below.) (Adjust ioY to the IO processor where STSsw is executing.) Either start the TelORB processor consoles on e.g. IO processor 1 as follows: cd /opt/telorb/consolelogs ./toX_cons_ioY (Change to valid file name) or start them on a local workstation/PC as follows: In the previously opened shell window named "toXCons": cd /home/telorb/labSystems/targetSystems/toX/consolelogs/ Either open the file toX_cons_ioY and send the lines manually or run the file as follows: ./toX_cons_ioY (E.g. ./to14_cons_io1)

General
From AD11 and higher, the STS (Software Terminal Server) is replacing the HW
based terminal server (Xyplex), or can be used in addition to it. The
disadvantage with STS is that it does not show the beginning of the TelORB
processor loading phase (bootstrap loader part).

STS makes it possible to get log files and consoles for each of the TelORB
processors.

STS places TelORB processor log files on one of the IO processors below
directory /opt/telorb/consolelogs/, if the parameter -log is entered when
starting STSsw in file /opt/telorb/etc/start_services. The directory
/opt/telorb/consolelogs/ must exist before STSsw is started.
In addition to these log files, it is of course possible to also have log files
on your local WS or elsewhere, but it should be enough to have the log files
started on one of the IO processors.

The TelORB processor consoles are preferably started on a local WS connected to
Pink LAN from e.g. directory
/home/telorb/labSystems/targetSystems/toX/consolelogs/.

For further information about STS, see STS (Software Terminal Server) or enter
the following command, which will show the following help text:
  /ipims_dicos/BS2/tbAD13/DICOS_IDPG/Unix_IDP/STSsw_LM/bin/STSsw.LM_D14.R1H03.solaris 
Parameters: a b [-portPORT] [-log [-dirDIR] [-sizeSIZE]]
a:    The number of processors in your traffic system.

b:    The port number to be used for the first telnet setup server.

      There will be as many setup servers created as the number of
      traffic processors in your system <a>.

      The first server will use port <b> and handle output from processor 1.
      The second server will use port <b+1> and handle output from processor 2.
      The n'th server will use port <b+n-1> and handle output from processor n.

PORT: Port number on which output from the TelORB system is expected.
      It will default to 7000. If you specify this parameter, you MUST MAKE
      SURE the config data "UDPConsolePort" in the TelORB system has the same
      value.

-log: If specified, printouts will be written to files.

      The files are called "log1", "log1.b", "log2", "log2.b" etc. 
      logN is continuously updated with printouts from processor N.
      When logN has grown bigger than the maximum file size, the file
      is copied "over" to logN.b and new printouts will go into a "clean" logN.

      Default directory for log files is /opt/telorb/consolelogs and must exist.

      Default max log file size is 2000000.

DIR:  Directory for the log files if the default is not suitable.
      The directory must exist.

SIZE: The maximum log file size if the default is not suitable

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Files that are involved in managing TelORB processor log files and consoles
- /etc/rc3.d/S34Dhcp_isc         (Start of DHCPD, just points at start_dhcp)

- /opt/telorb/etc/start_dhcp     (Start of DHCPD, just points at dhcpd.pxe.conf)

- /opt/telorb/etc/dhcpd.pxe.conf (Start of DHCPD and execution of the Dhcp
                                  processes which should be executing on both
                                  IO processors, e.g.
      /bin/csh -f /opt/telorb/codearchive/Unix_IDP/Dhcp_LM/scripts/Dhcp.io.csh /opt/t...
                                  and
      ./Dhcp.LM_D54.R1A07.solaris -lf /opt/telorb/etc/dhcpd.leases -cf /opt/telorb/et...)

  Make sure that the IP address value of consoleServerAddress in the
  dhcpd.pxe.conf file is the same on both IO processors, e.g. 134.138.76.26.

- /opt/telorb/etc/start_services (Start of STSsw and execution of the STSsw
                                  processes on one of the IO processors, e.g.
                                  ./STSsw.LM_D14.AD905p5.solaris 7 7001 -log
                                  /bin/csh /opt/telorb/tools/bin/STSsw 7 7001 -log)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start TelORB processor log files on one of the IO processors
- Log in to the IO processor that will host the TelORB processor log files.
  (Preferably, use the previously opened shell window named "toXLogs".)

- Check that the directory /opt/telorb/consolelogs/ exists, e.g.:
    drwxr-xr-x   2 telorb   telorb      1024 Mar 29 23:15 consolelogs/

- Check if STSsw is executing: 
    ps -ef | grep STS

- If STSsw is executing, the TelORB processor log files are probably already
  started.
  Proceed with Start TelORB processor consoles on e.g. a WS, unless the log files
  are to be restarted, which is described in the next section.

- If STSsw is not executing, start STSsw by either sending the STSsw part in the
  file /opt/telorb/etc/start_services. Make sure that the parameter -log is
  included in the STSsw command.
  Another way of starting STSsw is to reboot the IO processor as described in
  section Reboot / Power off IO processor. Make sure
  that the parameter -log is included in the STSsw command in the start_services
  file. Note that the reboot will affect all other processes that are running on
  the IO processor that is being rebooted.
  Proceed with Start TelORB processor consoles on e.g. a WS, unless the log files
  are to be restarted, which is described in the next section.

-- -- -- -- -- --

New from TSP 4 patch 8 (R14lp8) and TSP 5.0 LSV505 (Updated: 2003-11-07)
A new way of opening the TelORB processor console windows is introduced
(for security reasons), i.e. "localhost" is used instead of e.g. "to13io1"
in the xterm strings.
Example:
  xterm -ls -sb -fn 8x13 -geometry 70x8+40+150 -sl 10000 -title "Dicos_Proc_m0_s9_Loader" -e tcsh -c 'telnet localhost 7001' &
  (Always start with port 7001)

In addition to this, to make Ctrl-c work in the consoles, the .telnetrc
file on the IO processor(s) should be modified. It is now only necessary
to include the following line in the /home/telorb/.telnetrc file,
located on the IO processors:
  localhost unset interrupt

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Clear and restart TelORB processor log files on IO processor 1
 (Updated: 2003-07-03)
The log files on IO1 are cleared and restarted as follows:

- Go to directory /opt/telorb/consolelogs/ on IO1:
    cd /opt/telorb/consolelogs/

- Remove current logs:
    rm Proc_m*   (Make sure no other files starting with "Proc_m" are to be
                  kept!)

- Stop and start TelORB services (or do as specified in the old description
  below, i.e. kill the STS process):
    /opt/telorb/etc/stop_services      (Note that e.g. TelORB processor consoles
                                        will be closed)
    /opt/telorb/etc/start_services

- Check that new log files have been created, e.g. Proc_m0_s9, Proc_m0_s11, etc:
    ls -l

- Start the TelORB processor consoles on IO1.


Old info for jurasic releases:
- Go to directory /opt/telorb/consolelogs/ on the relevant IO processor:
    cd /opt/telorb/consolelogs/
- Remove current logs from directory consolelogs, if any (not necessary):
    rm log*    (Make sure no other files starting with "log" are to be kept!)
- Check PID for STS:
    ps -ef | grep STS
      telorb   276     1  0 13:22:53 ?        0:00 /bin/csh /opt/telorb/tools/bin/STSsw 7 7001 -log
        (guard for TelORB release AD12 and lower. For R14: /bin/csh -f ./guardSts 28 7001 -log)
      telorb   561   430  0 12:32:26 ?        0:01 ./STSsw.LM_D14.R1I02.sparc-SunOS-5.6 28 7001 -log
        (STS)
- Kill the STS process (not the STS guard) pointed out by the ps command above:
    kill <PID>
    All TelORB processor consoles will be closed.
- Check that a new STS process is running (different PID):
    ps -ef | grep STS
- Check that new log files have been created, i.e. log1, log2,...:
    ls -l
- Start the TelORB processor consoles.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Move the execution of the TelORB processor log files and consoles from IO1 to IO2
(This section has not yet been verified, but I think it is correct.)

- Close all TelORB processor consoles.

- Stop the STS processes, which are executing on IO1, e.g kill the processes
  which look something like this:
    telorb  9130  9114  0 10:11:11 pts/0    0:00 ./STSsw.LM_D14.AD905p5.solaris 7 7001 -log
    telorb  9114   267  0 10:11:11 pts/0    0:00 /bin/csh /opt/telorb/tools/bin/STSsw 6 7001 -log
    E.g. kill 9130 9114 267

- In the file /opt/telorb/etc/dhcpd.pxe.conf, on both IO processors, change the
  line
    option consoleServerAddress 134.138.76.25;      (Adjust 76 to valid ethernet
                                                     address)(25=IO1)
  to
    option consoleServerAddress 134.138.76.26;      (Adjust 76 to valid ethernet
                                                     address)(26=IO2)
  The IP address value of consoleServerAddress must be the same on both IO
  processors, e.g. 134.138.76.26.

- Stop and start DHCPD on both IO processors:
    cd /etc/rc3.d/
    su
    ./S34Dhcp_isc stop
    ./S34Dhcp_isc start

- Start the STS processes on IO2, e.g.:
    /opt/telorb/tools/bin/STSsw 6 7001 -log &       (Adjust 6 to the number of
                                                     TelORB processors)
  If IO2 shall host the TelORB processor consoles permanently, also change the
  file /opt/telorb/etc/start_services on both IO processors, i.e. remove or
  comment out the STS startup line
  (e.g. "/opt/telorb/tools/bin/STSsw 6 7001 -log &")
  from IO1 and add it to IO2.

- It is necessary to reload the corresponding TelORB processor(s), since they
  must re-read the dhcpd.pxe.conf file.

- Open all TelORB processor consoles.

The execution of the TelORB processor log files and consoles will now be on IO2.

  (The option "consserverip 134.138.59.101" has been removed from the
   telorb.conf file. Instead this is hardcoded to direct the consoles only to
   IO1.
   This will probably be changed, so that if the console server location (IO1 or
   IO2) is entered in telorb.conf, the consoles will be directed to the
   specified IO processor. If it is not specified, IO1 will be used as a
   default. (2001-11-21))
  (The consserverip parameter is now back in the telorb.conf file. (2002-01))

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start TelORB processor consoles on e.g. a WS
- Quit all present TelORB processor consoles, if any.
  (A fast way to quit a console is to position the mouse pointer in the console
  to quit and then press the keys "Alt" and "F4" simultaneously. (Might not work
  on all workstations.))

- Preferably, use the previously opened shell window named "toXCons" and go to
    /home/telorb/labSystems/targetSystems/toX/consolelogs/.      (Adjust toX to
                                                                  valid TelORB
                                                                  system)

- Run the file that contains the start up commands for all TelORB processors,
  e.g. file toX_cons_ioY (make sure that STSsw is started on the IO processor
  to direct the xterm command to):
    ./toX_cons_ioY                            (Adjust toX to valid TelORB system
                                               and ioY to valid IO processor)
  
  If a file that contains the startup commands does not exist, create it by
  using the template below or just run one or several lines from the template.
  Be sure to adjust toXioY to valid TelORB system and IO processor.
  
  ----- Template for starting TelORB processor consoles -----
#! /bin/sh

xterm -ls -sb -fn 8x13 -geometry 72x12+40+0    -sl 10000 -title "Processor1" -e tcsh -c 'telnet toXioY 7001' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+0   -sl 10000 -title "Processor2" -e tcsh -c 'telnet toXioY 7002' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+200  -sl 10000 -title "Processor3" -e tcsh -c 'telnet toXioY 7003' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+200 -sl 10000 -title "Processor4" -e tcsh -c 'telnet toXioY 7004' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+400  -sl 10000 -title "Processor5" -e tcsh -c 'telnet toXioY 7005' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+400 -sl 10000 -title "Processor6" -e tcsh -c 'telnet toXioY 7006' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+600  -sl 10000 -title "Processor7" -e tcsh -c 'telnet toXioY 7007' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+600 -sl 10000 -title "Processor8" -e tcsh -c 'telnet toXioY 7008' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+800  -sl 10000 -title "Processor9" -e tcsh -c 'telnet toXioY 7009' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+800 -sl 10000 -title "Processor10" -e tcsh -c 'telnet toXioY 7010' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+0    -sl 10000 -title "Processor11" -e tcsh -c 'telnet toXioY 7011' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+0   -sl 10000 -title "Processor12" -e tcsh -c 'telnet toXioY 7012' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+200  -sl 10000 -title "Processor13" -e tcsh -c 'telnet toXioY 7013' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+200 -sl 10000 -title "Processor14" -e tcsh -c 'telnet toXioY 7014' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+400  -sl 10000 -title "Processor15" -e tcsh -c 'telnet toXioY 7015' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+400 -sl 10000 -title "Processor16" -e tcsh -c 'telnet toXioY 7016' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+600  -sl 10000 -title "Processor17" -e tcsh -c 'telnet toXioY 7017' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+600 -sl 10000 -title "Processor18" -e tcsh -c 'telnet toXioY 7018' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+800  -sl 10000 -title "Processor19" -e tcsh -c 'telnet toXioY 7019' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+800 -sl 10000 -title "Processor20" -e tcsh -c 'telnet toXioY 7020' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+0    -sl 10000 -title "Processor21" -e tcsh -c 'telnet toXioY 7021' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+0   -sl 10000 -title "Processor22" -e tcsh -c 'telnet toXioY 7022' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+200  -sl 10000 -title "Processor23" -e tcsh -c 'telnet toXioY 7023' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+200 -sl 10000 -title "Processor24" -e tcsh -c 'telnet toXioY 7024' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+400  -sl 10000 -title "Processor25" -e tcsh -c 'telnet toXioY 7025' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+400 -sl 10000 -title "Processor26" -e tcsh -c 'telnet toXioY 7026' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+600  -sl 10000 -title "Processor27" -e tcsh -c 'telnet toXioY 7027' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+600 -sl 10000 -title "Processor28" -e tcsh -c 'telnet toXioY 7028' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+800  -sl 10000 -title "Processor29" -e tcsh -c 'telnet toXioY 7029' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+800 -sl 10000 -title "Processor30" -e tcsh -c 'telnet toXioY 7030' &

  ----- End of template -----

  If you want TelORB processor log files to appear in the directory
  /home/telorb/labSystems/targetSystems/toX/consolelogs/, just add the following
  string at the end of each line before the apostrophe (') and ampersand (&):
    " | tee logZ"                        (Adjust logZ to valid TelORB processor)
  so that the line looks something like
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+0    -sl 10000 -title "ProcessorZ" -e tcsh -c 'telnet toXioY 7001 | tee logZ' &

The directory /home/telorb/to14/consolelogs/ for TelORB system to14 is updated
with what is mentioned above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check bootstrap loader part - use tip from e.g. an IO processor
- Connect a serial cable with a null modem from e.g. an IO processor to the
  TelORB processor that is to be monitored.
- From a shell do telnet into the IO processor.
- su
- tip -38400 /dev/cua/b   (an example)
For further information about how to use tip, see
Connect to remote host using "tip".
- Exit tip by entering ~. (tilde and full stop).
- exit  (Return from superuser mode to telorb mode)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check bootstrap loader part - use a terminal server port from another TelORB system
Sometimes it is of interest to be able to see the TelORB processor bootstrap
loader part of the loading. For this purpose, a terminal server can be used.
If the TelORB system is not equipped with a terminal server, a terminal server
from another TelORB system can be used as follows:

  Either use a local WS or tos1/tos2.
  cd /home/dicostest/tosFiles/toX/consolelogs/ (Go to the directory consolelogs
                                                of a TelORB system with terminal
                                                server) (Adjust toX to valid
                                                TelORB system)
  setenv DISPLAY 134.138.186.xx:0.0   (Only valid if tos1/tos2 is used.
                                       Set IP address of the WS to display on.
                                       Adjust the IP address to the WS that you
                                       are working on)

Connect a cable from a free port on the terminal server in TelORB system toX to
a TelORB processor in the target TelORB system toY.

  more toX_cons_ioY                   (To start the TelORB processor console, an
                                       xterm line from the file toX_cons_ioY
                                       can be adjusted for this purpose. Adjust
                                       toX to valid TelORB system and ioY to
                                       valid IO processor.
                                       The file toX_cons_ioY was previously
                                       called START)

Use the xterm line that corresponds to the selected terminal server port, e.g.
for port 8 in TelORB system to3:
  xterm -ls -sb -fn 8x13 -geometry 72x13+660+600 -title "Processor8" -e tcsh -c 'telnet to3ts 2800 | tee log8' &
Remove the string
  " | tee log8"
if no log file is required.

If there is no xterm line in the toX_cons_ioY file that corresponds to the
selected terminal server port, create the xterm line yourself by using the logic
from the other lines in the toX_cons_ioY file. The first TS port is 2100 and
the port number is stepped with 100 for each port, i.e. 2100 = port 1,
2200 = port 2, ... , 2800 = port 8, ... , 3400 = port 14.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Make it possible to see what happens in the TelORB processor consoles when e.g.
powering off ethernet switch A
In the file /opt/telorb/etc/dhcpd.pxe.conf (tools installed by script) or
/etc/dhcpd.pxe.conf (tools installed manually), on both IO processors, change
the line "option consoleServerAddress..." from e.g.
  option consoleServerAddress 134.138.XX.25;    (E.g. XX=EthA)(25=IO1)(26=IO2)
to
  option consoleServerAddress 134.138.YY.25;    (E.g. YY=EthB)(25=IO1)(26=IO2)
so that the other net is used for the TelORB processor consoles. Enter superuser
mode to be able to modify the file.

Activate the modified settings:
  su                                       (Enter superuser mode)
  cd /etc/rc3.d/
  ps -ef | grep dhcp                       (Check that ~"/usr/sbin/dhcpd.isc -cf
                                            /etc/dhcpd.pxe.conf" is running)
  ./S34dhcpd_isc stop                      (or use kill)
  ps -ef | grep dhcp                       (Check that ~"/usr/sbin/dhcpd.isc -cf
                                            /etc/dhcpd.pxe.conf" is not running.
                                            If it still runs, kill by using the
                                            kill command)
  ./S34dhcpd_isc start
  ps -ef | grep dhcp                       (Check that ~"/usr/sbin/dhcpd.isc -cf
                                            /etc/dhcpd.pxe.conf" is running)


(Section verified for R13)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Make it possible to start lots of TelORB processor consoles on one WS
With the solution below it is possible to start all consoles for e.g. two 30
TelORB processor systems on one workstation without getting e.g. the printout
"xterm: no available ptys".

- Add the following lines to the file /etc/system:
   
    set pt_cnt=128
    set npty=128
    set sadcnt=256
    set nautopush=128
   
- After the file has been edited and saved:
   
    touch /reconfigure
   
- Reboot the client.
   
(Info from DATAHELP, 000622)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
If the TelORB processor consoles just appear for a short while on the screen and
then disappears, it is most probable that another user has the consoles started
elsewhere. Close the other user's consoles and retry.
Another way, if a terminal server is used, is to power the terminal server off
and on to reboot it, and then start the consoles once more.

If printouts do not appear on some or all TelORB processor consoles, it may be
worthwhile to reload the affected TelORB processors.

Files and processes that have with the TelORB processor consoles and logs to do
(valid for TelORB R14):
- File /opt/telorb/etc/dhcpd.pxe.conf   (/opt/telorb/etc/telorb.conf)
    (Line: option consoleServerAddress 134.138.67.225;)
- Processes started on one of the IO processors:
    ./STSsw.LM_D14.R1I02.sparc-SunOS-5.6 28 7001 -log
    /bin/csh -f ./guardSts 28 7001 -log
- Script for starting the TelORB processor consoles, e.g.
    ./toX_cons_ioY
- The system tox must be included in the file /home/telorb/.telnetrc on the IO
  processor where STS is executing.

In TelORB R14, if printouts do not appear on the TelORB processor consoles, it
may be worthwhile to check that the DHCP processes are executing on the IO
processors:
  cd /opt/telorb/etc/
  ./status_dhcp
    or
  ps -ef

More hints can be found in section Initial load TelORB system.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

New template script for when the console server is accessible from localhost only
 (Updated: 2003-09-23)

This security feature was introduced in TSP 4.0 patch 8 (R14lp8) as a correction
to HD92658 (Cluster ports are available for external access).

The ports specified for the consoles (e.g. 7001-7008 in a GEM-Micro) should be
available to the two internal networks only, i.e. not to any external interface.

The correction requires the following changes to the TelORB processor console
start script:
  - The telnet command should use localhost instead of the IO processor name
    (e.g. io1), and the telnet string should be surrounded by quotation marks
    (" "), instead of apostrophes (' '), e.g. "telnet localhost 7001" instead
    of `telnet io1 7001'.
    Note that the quotation marks may not work in all environments, but they
    work at the EAB CW/OS lab.
    See example script below.

In addition to this, to make Ctrl-c work in the consoles, the .telnetrc file
on the IO processor(s) should be modified.
See example file below.

Example script for starting the TelORB processor console logs for TelORB system
to28 in Älvsjö:

  #! /bin/sh

  xterm -ls -sb -fn 8x13 -geometry 72x12+40+200   -sl 10000 -title "linuxProc_m0_s3" -e tcsh -c "telnet localhost 7001" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+660+200  -sl 10000 -title "linuxProc_m0_s5" -e tcsh -c "telnet localhost 7002" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+400   -sl 10000 -title "dicosProc_m0_s7" -e tcsh -c "telnet localhost 7003" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+0     -sl 10000 -title "dicosProc_m0_s9_Loader" -e tcsh -c "telnet localhost 7004" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+660+400  -sl 10000 -title "linuxProc_m0_s11" -e tcsh -c "telnet localhost 7005" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+600   -sl 10000 -title "linuxProc_m0_s13" -e tcsh -c "telnet localhost 7006" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+660+600  -sl 10000 -title "dicosProc_m0_s15" -e tcsh -c "telnet localhost 7007" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+800   -sl 10000 -title "dicosProc_m0_s17" -e tcsh -c "telnet localhost 7008" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+800   -sl 10000 -title "dicosProc_m0_s19" -e tcsh -c "telnet localhost 7009" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+800   -sl 10000 -title "dicosProc_m0_s21" -e tcsh -c "telnet localhost 7010" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+660+800  -sl 10000 -title "linuxProc_m0_s23" -e tcsh -c "telnet localhost 7011" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+660+0    -sl 10000 -title "dicosProc_m1_s9_Loader" -e tcsh -c "telnet localhost 7012" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+40+900   -sl 10000 -title "dicosProc_m1_s11" -e tcsh -c "telnet localhost 7013" &
  xterm -ls -sb -fn 8x13 -geometry 72x12+660+900  -sl 10000 -title "linuxProc_m1_s13" -e tcsh -c "telnet localhost 7014" &


Yet another example (start_consoles):

# Start consoles for to13 : Dicos=White : Dicos-loader=Orange : Linux=Yellow : uabmsu
xterm -ls -sb -fn 8x13 -geometry 72x12+00+0    -sl 10000 -bg white  -title "Proc_m0_s1" -e tcsh -c 'telnet localhost 7001' &
xterm -ls -sb -fn 8x13 -geometry 72x12+640+0   -sl 10000 -bg yellow -title "Proc_m0_s5" -e tcsh -c 'telnet localhost 7002' &
xterm -ls -sb -fn 8x13 -geometry 72x12+00+200  -sl 10000 -bg orange -title "Proc_m0_s9" -e tcsh -c 'telnet localhost 7003' &
xterm -ls -sb -fn 8x13 -geometry 72x12+640+200 -sl 10000 -bg yellow -title "Proc_m0_s11" -e tcsh -c 'telnet localhost 7004' &
xterm -ls -sb -fn 8x13 -geometry 72x12+00+400  -sl 10000 -bg yellow -title "Proc_m0_s13" -e tcsh -c 'telnet localhost 7005' &
xterm -ls -sb -fn 8x13 -geometry 72x12+640+400 -sl 10000 -bg white  -title "Proc_m0_s15" -e tcsh -c 'telnet localhost 7006' &
xterm -ls -sb -fn 8x13 -geometry 72x12+00+600  -sl 10000 -bg white  -title "Proc_m0_s17" -e tcsh -c 'telnet localhost 7007' &
xterm -ls -sb -fn 8x13 -geometry 72x12+640+600 -sl 10000 -bg yellow -title "Proc_m0_s19" -e tcsh -c 'telnet localhost 7008' &
xterm -ls -sb -fn 8x13 -geometry 72x12+00+800  -sl 10000 -bg white  -title "Proc_m0_s21" -e tcsh -c 'telnet localhost 7009' &
xterm -ls -sb -fn 8x13 -geometry 72x12+640+800 -sl 10000 -bg white  -title "Proc_m0_s23" -e tcsh -c 'telnet localhost 7010' &

xterm -ls -sb -fn 8x13 -geometry 72x12+20+0    -sl 10000 -bg yellow -title "Proc_m1_s5" -e tcsh -c 'telnet localhost 7011' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+0   -sl 10000 -bg orange -title "Proc_m1_s9" -e tcsh -c 'telnet localhost 7012' &
xterm -ls -sb -fn 8x13 -geometry 72x12+20+200  -sl 10000 -bg yellow -title "Proc_m1_s11" -e tcsh -c 'telnet localhost 7013' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+200 -sl 10000 -bg white  -title "Proc_m1_s13" -e tcsh -c 'telnet localhost 7014' &
xterm -ls -sb -fn 8x13 -geometry 72x12+20+400  -sl 10000 -bg yellow -title "Proc_m1_s15" -e tcsh -c 'telnet localhost 5' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+400 -sl 10000 -bg yellow -title "Proc_m1_s17" -e tcsh -c 'telnet localhost 7016' &
xterm -ls -sb -fn 8x13 -geometry 72x12+20+600  -sl 10000 -bg yellow -title "Proc_m1_s19" -e tcsh -c 'telnet localhost 7017' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+600 -sl 10000 -bg white  -title "Proc_m1_s21" -e tcsh -c 'telnet localhost 7018' &
xterm -ls -sb -fn 8x13 -geometry 72x12+20+800  -sl 10000 -bg white  -title "Proc_m1_s23" -e tcsh -c 'telnet localhost 7019' &

xterm -ls -sb -fn 8x13 -geometry 72x12+40+0    -sl 10000 -bg yellow -title "Proc_m3_s1" -e tcsh -c 'telnet localhost 7020' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+0   -sl 10000 -bg white  -title "Proc_m3_s5" -e tcsh -c 'telnet localhost 7021' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+200  -sl 10000 -bg yellow -title "Proc_m3_s7" -e tcsh -c 'telnet localhost 7022' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+200 -sl 10000 -bg white  -title "Proc_m3_s9" -e tcsh -c 'telnet localhost 7023' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+400  -sl 10000 -bg yellow -title "Proc_m3_s11" -e tcsh -c 'telnet localhost 7024' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+400 -sl 10000 -bg white  -title "Proc_m3_s13" -e tcsh -c 'telnet localhost 7025' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+600  -sl 10000 -bg yellow -title "Proc_m3_s15" -e tcsh -c 'telnet localhost 7026' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+600 -sl 10000 -bg white  -title "Proc_m3_s17" -e tcsh -c 'telnet localhost 7027' &
xterm -ls -sb -fn 8x13 -geometry 72x12+40+800  -sl 10000 -bg yellow -title "Proc_m3_s19" -e tcsh -c 'telnet localhost 7028' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+800 -sl 10000 -bg white  -title "Proc_m3_s21" -e tcsh -c 'telnet localhost 7029' &

xterm -ls -sb -fn 8x13 -geometry 72x12+60+0    -sl 10000 -bg yellow -title "Proc_m4_s1" -e tcsh -c 'telnet localhost 7030' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+0   -sl 10000 -bg white  -title "Proc_m4_s5" -e tcsh -c 'telnet localhost 7031' &
xterm -ls -sb -fn 8x13 -geometry 72x12+60+200  -sl 10000 -bg yellow -title "Proc_m4_s7" -e tcsh -c 'telnet localhost 7032' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+200 -sl 10000 -bg white  -title "Proc_m4_s9" -e tcsh -c 'telnet localhost 7033' &
xterm -ls -sb -fn 8x13 -geometry 72x12+60+400  -sl 10000 -bg yellow -title "Proc_m4_s11" -e tcsh -c 'telnet localhost 7034' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+400 -sl 10000 -bg white  -title "Proc_m4_s13" -e tcsh -c 'telnet localhost 7035' &
xterm -ls -sb -fn 8x13 -geometry 72x12+60+600  -sl 10000 -bg yellow -title "Proc_m4_s15" -e tcsh -c 'telnet localhost 7036' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+600 -sl 10000 -bg yellow -title "Proc_m4_s17" -e tcsh -c 'telnet localhost 7037' &
xterm -ls -sb -fn 8x13 -geometry 72x12+60+800  -sl 10000 -bg yellow -title "Proc_m4_s19" -e tcsh -c 'telnet localhost 7038' &
xterm -ls -sb -fn 8x13 -geometry 72x12+660+800 -sl 10000 -bg white  -title "Proc_m4_s21" -e tcsh -c 'telnet localhost 7039' &
xterm -ls -sb -fn 8x13 -geometry 72x12+60+800  -sl 10000 -bg white  -title "Proc_m4_s23" -e tcsh -c 'telnet localhost 7040' &


An example of a stop consoles script (stop_consoles.csh):

#!/bin/csh -f

foreach i (`ps -fw | grep xterm | grep Proc | gawk '{print $2}'`)
     kill $i
end


Example of .telnetrc file on the IO processor(s) for IO1 in TelORB system
to28 in Älvsjö (/home/telorb/.telnetrc):
  to28io1
          unset interrupt
  localhost
          unset interrupt
  127.0.0.1
          unset interrupt

Step 1: Prerequisites
- If TelORB processor consoles are not already started:
    Start the TelORB processor consoles as described in
    Start TelORB processor log files and consoles.
    Type "Ctrl-c" and "Enter" in all TelORB processor consoles to stop the
    TelORB processors from executing.
    If "Ctrl-c" does not work, see "Hints" below.

- If TelORB processor consoles are already started and TelORB processors are
  executing:
    Type "Ctrl-c" and "Enter" in all TelORB processor consoles to stop the
    TelORB processors from executing.
    Actually, it is enough to type "Ctrl-c" and "Enter" in the consoles for
    TelORB processors 1 and 2, since this will stop all TelORB processors from
    executing.
    If "Ctrl-c" does not work, see "Hints" below.
        (Not necessary to type "Ctrl-c" and "Enter" in windows that show:
        "ColspPromLoader::entering the while loop".)

Hints
-----
- If it is not possible to use "Ctrl-c" in a TelORB processor console to
  stop a TelORB processor from executing (e.g. the console window just
  disappears when entering "Ctrl-c"), do the following on the WS that displays
  the consoles, e.g. on client uabs31i1c50:
    cd /home/telorb/
    ls -la
    Modify the file .telnetrc so that it looks as follows for each terminal
    server, STS or IO processor:
      # command lines must begin with a whitespace
      to1ts
	      unset interrupt
        :
      to15ts
	      unset interrupt
        :
      to8io1        
              unset interrupt
      to8io2        
              unset interrupt


Step 2: Initial load the TelORB system
- Type "q" (and "q") in all stopped TelORB processor consoles, except for
  TelORB processor 2, to start the execution in the TelORB processors.  
  It is extremely important that TelORB processor 2 is manually halted during
  the first part of the loading, which always should be performed by TelORB
  processor 1. (Some ways of manually halting TelORB processor 2:
                Either
                - Type "Ctrl-c" and "Enter" in the console for TelORB processor
                  2.
                or
                - Disconnect the ethernet cables between TelORB processor 2 and
                  the ethernet switches.
                  Wait until the printout described below is shown in the TelORB
                  processor console for TelORB processor 1.
                  Connect the ethernet cables and poke the reset button on the
                  TelORB processor 2 board once.
                or
                - Poke the reset button on the TelORB processor 2 board several
                  times until the printout described below is shown in the
                  TelORB processor console for TelORB processor 1.)

- When the TelORB processor console for TelORB processor 1 shows the line
  "Waiting for all processors to connect to CM..."
  type "q" (and "q") also in the halted TelORB processor console for TelORB
  processor 2.
      (It is not possible to perform the initial load using TelORB processor 2
      as primary loader. However, reloading the TelORB system with TelORB
      processor 2 as primary loader works.)
  Note: In TSP 5, the CM will wait forever until all processors have connected,
        whereas in earlier releases, the printout "ERROR: Couldn't load total
        functionality - initial start is hanging." is received after some
        minutes. This printout still exists in TSP 5, but only in case of other
        non-waiting errors.

- Wait for all TelORB processors to initial load, i.e. until the printout
  "-----> Total functionality started." is received in all TelORB processor
  consoles.
  When this printout is received in all TelORB processor consoles, the TelORB
  system is successfully loaded.
  If not, see "Hints" below.

Hints
-----
- Some explanations and an example of the printouts received in the TelORB
  processor logs, are found by following the link below:
  The initial TelORB start-up

- If e.g. the following printout is received:
    connectStatus->
    | 1 | 1 | 1 | 0 | 1 | 1 |
  the PLGL cannot establish contact with TelORB processor 6. The first "1"
  represents TelORB processor 3 and the last "1" represents the non-loading
  PLGL.

- If the TelORB system does not load, there may be a problem with the access
  rights to e.g. the loading groups on the IO processors. Make sure that the axe
  and the loading group directories recursively has the owner and group rights
  `telorb', e.g.
      drwxr-sr-x   9 telorb   telorb       512 Apr 27 07:50 loadingGroup01_1

- Monitor DHCP during TelORB processor reload:
    Start recording (4 hits is normal for each processor reload):
      su                                (Enter superuser mode)
      snoop -o /tmp/output udp port 67  (/tmp/output=log file, 67=dhcp port)
                                        (Ctrl-C stops the recording)
      exit                              (Exit superuser mode)

    View recording result:
      snoop -i /tmp/output -x 0 -v


Step 3: Check "doRela" (undefined symbol)
Check the TelORB processor consoles for the string "doRela", especially during
initial load and reload. "doRela" should never appear, since, if it does, the
the LM where the doRela occurred does not know where to continue.
If a doRela is detected in a console, fix the problem in the LM or issue a
trouble report.

A "doRela" printout may look as follows:
Elf::doRela: symbol DeekSyslog_getUnAckedPacket is undefined at 0x0
  or
Elf::doRela: symbol JVM_DefineClass is undefined at 0x0
  or
Elf::doRela: symbol JVM_FindClassFromClass is undefined at 0x0

Fast way of checking doRelas:
  cd /opt/telorb/consolelogs/
  grep -i dorela log*

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Extra feature: Specify IOR for the populator, if it is included
After the initial load, the IOR of the populator will be output in the TelORB
processor logs for either TelORB processor 1 or 2. The printout looks as
follows:
"OBJECT REFERENCE FOR popgui IS: IOR:...".

Log in to IO processor 1 and copy the string "IOR:...", fetched from the TelORB
processor log, into a file named /opt/Populator/populator.ior.
Be careful as you cannot have end of line characters in this file

The other part of the populator, runs on the IO board.
The Populator files for the IO are attached and should be untared 
on /opt/Populator on the IO board. (same place where populator.ior
is located (see paragraph above)).

The following information is a description on how to initiate subscribers by
using the populator. This information will later be moved to its correct place
in these guidelines (due to lack of time for the moment).
How to customize PopGUI
        - All values are stored in the PopGui.ini file
          You can edit this file to meet your needs

          You can also run the metapop script (./metapop)
          which will create different PopGui.ini files
          and automatically run them.
          This script uses the PopGui.ini.A and PopGui.ini.B
          files.

How to start Populator
        - First : Start TelORB
        - Second: Some elements must be in the database (using CORBA) 
                        NetworkElement, 
                        NetworkEntity, 
                        SSN
                (see CORBA scripts email for info).

        - Third :
                Start the PopGUI typing "populator.csh Popgui.ini" 
                at the unix prompt on the IO board.

A request will be sent to Telorb and you should see RED load on a
processor.
Rate: about 2000 subs per minute.

Populator support at LMC
------------------------
Ludovic Beliveau  (lmclube)
mobile: 823-2563
office: ext. 2142


Hints
-----
- To check the MAC address settings when the system is up and running:
  Go to /opt/telorb/axe/loadingGroup01_X/ on IO processor X and type
    more networkAddresses

- From TSP 5.0 LSV 506, the way of initially configuring TelORB is changed,
  i.e. the following applies (e-mail from Stefan Näslund, 2003-12-16):
    For "non-Vega" systems I have changed the implementation in the Dicos
    loading so that the processors' MAC addresses are now fetched from the
    site database instead of the networkAddresses file as before.
    epct now generates the networkAddresses file *only* in case of Vega.
  The new way of initially configuring TelORB is described in Lars Ekman's
  document Initial configuration.

- A MAC address is the same as an ethernet address, but not the same as an
  IP address. An example of a MAC (ethernet) address is "00:30:f7:00:c1:bd"
  and an example of an IP address is "134.138.57.101".

Log in to a TelORB processor with Linux OS
 (Updated: 2003-08-14)

TSP 4
-----
From one of the IO processors:
  telnet 172.18.100.103           (As telorb user)(Adjust IP address)
                                  (Alternative: telnet -l telorb 172.18.100.103)
  login:

  date                            (Check date and time)
    Wed Sep 11 14:52:31 UTC 2002  (UTC is the default value if timezone has not
                                  been specified in /opt/telorb/etc/telorb.conf)

TSP 5
-----
From one of the IO processors:
  ssh 172.16.100.109              (Adjust to valid IP address)

Continous printouts and inputs:

The authenticity of host '172.16.100.109 (172.16.100.109)' can't be established.
RSA key fingerprint is 05:4d:04:8d:34:18:73:51:bd:5c:67:d5:82:31:88:57.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.100.109' (RSA) to the list of known hosts.
telorb@172.16.100.109's password: telorb
########################################################################
#      This system is for the use of authorized users only.	       #
#      Individuals using this computer system without authority, or in #
#      excess of their authority, are subject to having all of their   #
#      activities on this system monitored and recorded by system      #
#      personnel.                                                      #
#                                                                      #
#      In the course of monitoring individuals improperly using this   #
#      system, or in the course of system maintenance, the activities  #
#      of authorized users may also be monitored.                      #
#                                                                      #
#      Anyone using this system expressly consents to such monitoring  #
#      and is advised that if such monitoring reveals possible         #
#      evidence of criminal activity, system personnel may provide the #
#      evidence of such monitoring to law enforcements officials.      #
########################################################################

/usr/X11R6/bin/xauth:  creating new authority file /home/telorb/.Xauthority
tset: unknown terminal type sun-cmd
Terminal type? xterm                         (Example of values: xterm or vt100)
telorb@linux:~> 

Some useful commands:

  more /etc/redhat-release   (Check version of Red Hat release
                              E.g. "Red Hat Linux release 7.1 (Seawolf)")
  ps -ef                     (Check which processes that are executing)

  cd /proc/                  (Check which processes that are executing)
  ls -l
  cd <PID>                   (E.g. cd 9758)
  more cmdline               (Mostly lmstarter)

  su
  reboot -f                  (Reboot the processor that you are logged in to)

  kill -sigbus <PID>         (Kill a PID to e.g. get a Linux core dump.
                              Instead of -sigbus you can use -7)
                             (e.g. you can kill a /var/opt/telorb/bin/lmstarter
                              process)

  kill -sigsegv <PID>        (Kill a PID to e.g. get a Linux core dump)
                              Instead of -sigsegv you can use -11)
  Linux core dumps are initially put in directory /var/crash/core/ on the TelORB
  processor where they occur, but is then moved to directory /tmp/ on the TelORB
  processor from where they are being sent to both IO processors.

Hints:
If the following message is received when trying to login:
  "Add correct host key in /home/uabmsu/.ssh/known_hosts to get rid of this message."
then remove the line corresponding to the host that you are trying to login to
in the file /home/uabmsu/.ssh/known_hosts, e.g.
  "to28io1,134.138.187.113 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxNEfiwUJEIvTpw8cpA2G
2KYgjwHwJcfWh0+MpuRBbgNealb4BNF412K6+WgbevsYUX3dcozE6Xt11UVZ7mIyp2CEAZ0Tblexbv7x
TQ7GNlEGfuoNmW+bztObgYNNtHYLmdUAHJBp7bbt4pu5bU1qKL884CQS4Fh2/OM/k23aBpk=
134.138.187.59 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAsD3rKTYaqdimZXq3arnJWusiEaYwY
aK2FIgTrPSv/PnrydCT2YMV8UN30f1vAUQ8x1gHHa+TbYfJXdOeYePF5hRWTzBavr8uDthL7zTmWEJeV
Tsl/Ro+j4VOQyiEWY+SHAz4sX2+dD/7t0E3iiQrcKZ5hKYe6FY1p/53mZT7Y8s="

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Printout from when loading a TelORB processor with Linux OS
 (Updated: 2001-11-27)

The TelORB processor, in this printout example, has four ethernet interfaces,
i.e. eth0, eth1, eth2 and eth3. A serial terminal was used to get the printout.
The printout was taken from TelORB processor 15 in an 18 processor system
(to28), using the software release TelORB R14p7, drop 2.2, preDrop 2.3.
Note that the printout sequence may have changed, if you are using a later
release than what is specified above.

Note: To get also the application information in the printout, do not use
      "dmesg", but use "tip" from a Solaris machine or use "minicom" from a
      Linux machine, e.g. from the IO processor.
      (Application information: E.g. from "Welcome to TSP (Red Hat) Linux" until
      "Starting crond: [  OK  ]".)

-------------------- Start of printout example --------------------
Linux version 2.4.8-tsp5 (stefanb@pelargir) (gcc version 2.96 20000731 (Red Hat Linux 7.11
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
128MB HIGHMEM available.
On node 0 totalpages: 262144
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 32768 pages.
Kernel command line: ks console=ttyS0,38400
Initializing CPU#0
Detected 698.145 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1392.64 BogoMIPS
Memory: 962908k/1048576k available (1340k kernel code, 85280k reserved, 490k data, 216k i)
Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU serial number disabled.
CPU: Intel Pentium III (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb260, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14)
Starting kswapd v1.8
allocated 32 pages and 32 bhs reserved for the highmem bounces
VFS: Diskquotas version dquot_6.4.0 initialized
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI Id
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
block: 128 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 196608K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
hda: SanDisk SDCFB-8, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 15680 sectors (8 MB) w/1KiB Cache, CHS=245/2/32
Partition check:
 hda: hda1
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eeprol
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.s
PCI: Found IRQ 12 for device 00:10.0
eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:A0:A5:50:01:59, IRQ 12.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 000100-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
  Receiver lock-up workaround activated.
PCI: Found IRQ 11 for device 00:13.0
eth1: Intel Corporation 82557 [Ethernet Pro 100] (#2), 00:A0:A5:50:01:5A, IRQ 11.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 000100-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
  Receiver lock-up workaround activated.
eth2: Intel Corporation 82559ER, 00:80:37:8F:34:88, IRQ 10.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 000000-000, Physical connectors present:
  Primary interface chip None PHY #0.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0xdbd8681d).
  Receiver lock-up workaround activated.
eth3: Invalid EEPROM checksum 0xda8f, check settings before activating this device!
eth3: Intel Corporation 82559ER (#2), 00:80:37:8F:34:89, IRQ 12.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 000000-000, Physical connectors present:
  Primary interface chip None PHY #0.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0xdbd8681d).
  Receiver lock-up workaround activated.
atp.c:v1.09 8/9/2000 Donald Becker <becker@scyld.com>
  http://www.scyld.com/network/atp.html
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected Intel 440GX chipset
agpgart: AGP aperture is 64M @ 0xe0000000
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.99 on Intel 440GX @ 0xe0000000 64MB
[drm] Initialized radeon 1.1.1 20010405 on minor 1
usb.c: registered new driver hub
PCI: Found IRQ 15 for device 00:07.2
uhci.c: USB UHCI at I/O 0xe000, IRQ 15
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: :USB Universal Host Controller Interface driver
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 65536k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 216k freed
INIT: version 2.78 booting
                @(#) : 0/0000-0/XXX 000 0000 Uen, Rev PR0A00 $

                        Welcome to TSP (Red Hat) Linux
                Press 'I' to enter interactive startup.
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
Setting clock  (utc): Mon Jan  4 20:45:51 CET 1999 [  OK  ]
Activating swap partitions:  [  OK  ]
Setting hostname eqmffsff:  [  OK  ]
Finding module dependencies:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling swap space:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Setting network parameters:  [  OK  ]
Bringing up interface lo:  [  OK  ]
Bringing up interface eth0:  [  OK  ]
Bringing up interface eth1:  [  OK  ]
Starting portmapper: [  OK  ]
Starting system logger: [FAILED]
Starting kernel logger: [  OK  ]
Initializing random number generator:  [  OK  ]
Starting ntpd: [  OK  ] server: [  OK  ]
Mounting other filesystems:  [  OK  ]
Starting up APM daemon: [  OK  ]
Starting sshd [  OK  ]
Starting xinetd: [  OK  ]
Starting keytable [  OK  ]
Starting crond: [  OK  ]
Starting tsp NFS: NFSv3 not supported.
nfs warning: mount version older than kernel
NFS: NFSv3 not supported.
nfs warning: mount version older than kernel
[  OK  ]
user_adapt: TIPC: Compiled at Nov  9 2001 11:34:39 start...
user_adapt: TIPC: Starting in processor [1,1,15] 8191, 4000
-----> Own Address = [1.1.15]
Media Ethernet-A/eth0 registered
Media Ethernet-B/eth1 registered
socket_adapt: TIPC: Socket adaptation started. sockops = f8858ee0
user_adapt: TIPC: successfully registered with major number 254
-----> Established link through Ethernet-B/eth1 to [1.1.7]
-----> Established link through Ethernet-A/eth0 to [1.1.7]
-----> Established link through Ethernet-A/eth0 to [1.1.1]
-----> Established link through Ethernet-B/eth1 to [1.1.1]
-----> Established link through Ethernet-B/eth1 to [1.1.11]
-----> Established link through Ethernet-A/eth0 to [1.1.11]
-----> Established link through Ethernet-A/eth0 to [1.1.18]
-----> Established link through Ethernet-A/eth0 to [1.1.13]
-----> Established link through Ethernet-A/eth0 to [1.1.17]
-----> Established link through Ethernet-A/eth0 to [1.1.8]
-----> Established link through Ethernet-A/eth0 to [1.1.9]
-----> Established link through Ethernet-A/eth0 to [1.1.5]
-----> Established link through Ethernet-A/eth0 to [1.1.3]
-----> Established link through Ethernet-A/eth0 to [1.1.14]
-----> Established link through Ethernet-A/eth0 to [1.1.6]
-----> Established link through Ethernet-A/eth0 to [1.1.2]
-----> Established link through Ethernet-A/eth0 to [1.1.12]
-----> Established link through Ethernet-A/eth0 to [1.1.4]
-----> Established link through Ethernet-B/eth1 to [1.1.8]
-----> Established link through Ethernet-B/eth1 to [1.1.3]
-----> Established link through Ethernet-B/eth1 to [1.1.14]
-----> Established link through Ethernet-B/eth1 to [1.1.4]
-----> Established link through Ethernet-B/eth1 to [1.1.17]
-----> Established link through Ethernet-B/eth1 to [1.1.18]
-----> Established link through Ethernet-B/eth1 to [1.1.13]
-----> Established link through Ethernet-B/eth1 to [1.1.6]
-----> Established link through Ethernet-B/eth1 to [1.1.2]
-----> Established link through Ethernet-B/eth1 to [1.1.5]
-----> Established link through Ethernet-B/eth1 to [1.1.9]
-----> Established link through Ethernet-B/eth1 to [1.1.12]
-----> Established link through Ethernet-A/eth0 to [1.1.16]
-----> Established link through Ethernet-B/eth1 to [1.1.16]
-----> Established link through Ethernet-A/eth0 to [1.1.10]
-----> Established link through Ethernet-B/eth1 to [1.1.10]
--------------------- End of printout example ---------------------


From TelORB processor console:

-------------------- Start of printout example --------------------
(re)starting the CMA at Tue Nov 27 10:44:21 CET 2001 ...
INFO: Installing tipc, args = [eth0=1 eth1=1 zone=1 subnetwork=1 processor=15]
-----> Processes will be started with reason: DicosInitialStart 

DEBUG INFO: Using [/var/opt/telorb/LMs/ScriptRpmDuga.LM_D137.Code.R1D01.i486-Redhat-6.0] for 1024911

DEBUG INFO: Using [/var/opt/telorb/LMs/LinuxLoadReader.LM_D150.Code.R1A01.i486-Redhat-6.0] for 1019502

DEBUG INFO: Using [/var/opt/telorb/LMs/LinuxProcessorSupervision.LM_D152.Code.R1A01.i486-Redhat-6.0] for 1019500

DEBUG INFO: Using [/var/opt/telorb/LMs/LinuxJavaVM.LM_D158.Code.R1A01.i486-Redhat-6.0] for 1019597

DEBUG INFO: Using [/var/opt/telorb/LMs/LinuxVisibroker.LM_D157.Code.R1A01.i486-Redhat-6.0] for 1019600

DEBUG INFO: Using [/var/opt/telorb/LMs/De2Sub.LM_PRO401.Code.R1B06TSP7.i486-Redhat-6.0] for 524304

DEBUG INFO: Using [/var/opt/telorb/LMs/De2SubJava.LM_PRO402.Code.R1B07TSP7.i486-Redhat-6.0] for 1003291

DEBUG INFO: Using [/var/opt/telorb/LMs/De2Sub.LM_PRO401.Code.R1B06TSP7.i486-Redhat-6.0] for 524307

DEBUG INFO: Using [/var/opt/telorb/LMs/De2Pop.LM_PRO501.Code.R1B08TSP2.i486-Redhat-6.0] for 524311

-----> Starting replicated process(es) in DU(s) with id=1024911

-----> Starting replicated process(es) in DU(s) with id=1019502

-----> Starting replicated process(es) in DU(s) with id=1019500

-----> Starting replicated process(es) in DU(s) with id=1019597

-----> Starting replicated process(es) in DU(s) with id=1019600

-----> Base functionality started.

21400030 0 100100f 0 31000000 21100000 0 100100f 61a8 1 
-----> RPM 'vbrokerTP' started.

/opt/telorb/axe/loadingGroup01_1/codeArchive/TelorbLinuxJava.IDP_D38/LinuxJavaMain.LM_D148.Code.R1A02.i486-Redhat-6.0
21400030 0 100100f 0 31000000 21100000 0 100100f 61a8 1 
Starting Java for Traffic Processors...-----> RPM 'jreTP' started.

-----> Starting dynamic keyed process(es) in DU(s) with id=524304

-----> Starting dynamic keyed process(es) in DU(s) with id=1003291

-----> Starting replicated process(es) in DU(s) with id=524311

21400030 0 100100f 0 31000000 21100000 0 100100f 61a8 1 
-----> Total functionality started. PEPS_PERSSONrootrootROCK
--------------------- End of printout example ---------------------

The instructions below are valid for TSP 4.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions (Adjust version in the command lines below.) - Start TelORB Manager in TelORB R14 and TSP 4 (TelORB R14-Linux) from one of the IO processors: /opt/telorb/codearchive/iom_scripts/TelORBManager -alarms & Start TelORB Manager in debug mode: /opt/telorb/codearchive/iom_scripts/TelORBManager -debug-iiop -debug-orb -alarms & or just /opt/telorb/codearchive/iom_scripts/TelORBManager -debug-iiop -alarms & (One way of starting TelORB Manager in TSP 4.0 Clusterware & OS from a local workstation: source /ipims_dicos/BS2/tbAD14p7/IP_CONF_INFO/EnvSettings (Adjust tbAD14p7) source /ipims_dicos/BS2/tbTEST1.3/IP_CONF_INFO/EnvSettings (For Loadable Extras) setenv DISPLAY 134.138.186.xx:0.0 (Set IP address of the WS to display on) TelORBManager -alarms& (OK to disregard the following printouts: "Could not find extra NetRedMonitor" "Could not find extra LinuxDemoApp")) - Start TelORB Manager externally for TSP 4.0 (from WS or Linux PC in the EAB Älvsjö environment: If Linux PC, log in to e.g. tos2 as user telorb and issue the following commands: If WS, issue the following commands: source /ipims_dicos/BS2/tbAD14lp10.4/IP_CONF_INFO/EnvSettings source /ipims_dicos/BS2/tbTEST1.4/IP_CONF_INFO/EnvSettings (For Loadable Extras) TelORBManager -alarms& - Start TelORB Manager in TelORB R13 from one of the IO processors: /opt/telorb/codearchive/TELORB_MANAGER/bin/TelORBManager -alarms -netred& or /home/telorb/Examples/TelORBManager1.0/bin/TelORBManager -alarms -netred& - Start TelORB Browser up to and including TelORB AD12 from one of the IO processors: /home/telorb/Examples/TelorbBrowser5.4/bin/TelorbBrowser & Hint: To be able to copy a text string from outside the TelORB Manager and paste it into an optional white input field in the TelORB Manager, simply mark the text string and hit the copy button, then left-click the white input field, click the paste button and enter Ctrl-v.

General
To manage a TelORB system and to get alarms & notifications, one can either use
the TelORB Manager or the TelORB Browser. The TelORB Browser is not an official
TelORB product and it was used in releases earlier than R13.
From R13 and higher, the TelORB Browser is replaced by the TelORB Manager,
which will be included in the TelORB deliveries, i.e. the TelORB Manager is an
official TelORB product.
The TelORB Manager works best against R13, but is written in order to be
backwards compatible against AD12 too.
Since the TelORB Manager is an official product, it is included in the IO tools
package, i.e. after upgrading the IO tools package (IO processor software upgrade),
the TelORB Manager will be located below the directory /opt/telorb/codearchive/
on the IO processors.

The TelORB Manager/Browser, should be started on one or both IO processors which
belongs to the TelORB zone (as is the case for customer sites).
    (The TelORB Manager/Browser may also be started in a local EAB CW/OS lab net
     shell, e.g. from client uabs31i1cxx, with the command:
       /home/dicoshack/Hack/tools/TelorbBrowser5.4/bin/TelorbBrowser &   (adjust
       TelORB Browser version to suit the TelORB release in use).
     To make this work, the TelORB system must be physically connected to the
     EAB CW/OS lab net router, i.e. from EthA and EthB to the router.)

Specification of the notification types, sent from TelORB can be found in:
  /ipims_dicos/BS2/tbAD13/Management_SWILib/NotificationTypes_SWI/incl/DicosNotificationTypes.h
                                                (Adjust tbAD13 to valid release)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Instructions for the TelORB Manager
Since the TelORB Manager is an official product, it is included in the tools
package, i.e. after updating tools, the Manager will be located below the
directory /opt/telorb/codearchive/ on the IO processors.

The file Locations should exist below directory /opt/telorb/codearchive/ (copy
it from e.g. /home/telorb/Examples/). (Instead of having the Locations file
below this directory, you can send the following commands taken from the
Locations file:
  setenv JDK /usr/java1.1                      (Adjust version, e.g. java1.1.7B)
  setenv ORB /home/telorb/visijars.)
For further info about the Locations file, see Java JDK/JRE upgrade.

To fetch the TelORB Manager from another location, e.g. from
/home/telorb/Examples/ to an IO processor, do as follows from an IO processor:
  cd /home/telorb/Examples/
  ftp uabs31i1c50                  (To a WS)
  telorb                           (Enter name)
  psw                              (Type password)
  cd /home/dicoshack/Hack/tools/   (previously /home/uabcsru/Examples/)
  bin                              (Enter binary transfer mode)
  get TelORBManager1.0.tar         (Fetch TelORB Manager. Adjust 1.0 to
                                    valid version)
  get TelORBDocs.tar               (Fetch user documentation)
  by                               (Exit ftp)
  tar xf TelORBManager1.0.tar      (Extract tar file on current directory)
  tar xf TelORBDocs.tar            (Extract tar file on current directory)
  rm TelORBManager1.0.tar          (Remove tar file)
  rm TelORBDocs.tar                (Remove tar file)

Start the TelORB Manager, with a separate alarm window (optional) and a card for
managing network redundancy (optional), from one of the IO processors as
follows. For TelORB R14, the netred parameter can be omitted.
  Either start the Manager from the codearchive directory (released version):
    /opt/telorb/codearchive/TelORB_MANAGER/bin/TelORBManager -alarms -netred&
      (or TelORBManager1.0/bin/TelORBManager -alarms -netred&)

  or start the Manager from the Examples directory:
    /home/telorb/Examples/TelORBManager1.0/bin/TelORBManager -alarms -netred&

If no port number is specified when connecting to the TelORB Manager, the
default port number is 7111 (e.g. 134.138.xx.yy = 134.138.xx.yy:7111).
To be able to specify a different port number, e.g. 134.138.xx.yy:7000, the
desired port number must have been specified in inital data (?) (epct) in the
variable CosNamingResponderPort (?), e.g. CosNamingResponderPort = 7000.

If the printout "You must setenv JDK to point to the JDK", send the following
commands taken from the Locations file:
  setenv JDK /usr/java1.1                      (Adjust version, e.g. java1.1.7B)
  setenv ORB /home/telorb/visijars
(for further info, see Java JDK/JRE upgrade).

If the TelORB Manager hangs, it may be released by killing the process
DoamEventProcess in either TelORB processor 1 or 2 (most often in 2).
This process will automatically be started again.
(Log in to e.g. TelORB processor 2 using "telnet 134.138.xx.102 8100", enter
"ps", look for "DoamEventProcess" and enter "kill <PID>" to kill it.)

To start the TelORB Manager in your work environment at the EAB CW/OS lab (i.e.
not on one of the IO processors), do as follows:
  cd /home/dicoshack/Hack/tools/  (Go to where the TelORB Managers are located)
  ls -l                           (Select TelORB Manager to use, e.g.
                                   TelORBManager2.0 for R14)
  TelORBManager2.0/bin/TelORBManager -alarms -netred&   (Start TelORB Manager)
    or
  /home/dicoshack/Hack/tools/TelORBManager2.0/bin/TelORBManager -alarms -netred&


Note that TelORB Manager in TelORB R14 looks for visibroker in
/opt/3rdParty/vbroker/lib where it expects to find vbjorb.jar and vbjapp.jar.

Start TelORB Manager in debug mode (valid from TelORB R14cos):
  /opt/telorb/codearchive/iom_scripts/TelORBManager -debug-iiop -debug-orb -alarms &

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Change version of TelORB Manager
 (Updated: 2002-12-17)

This is a "hacker" instruction and should be used as such.
If you want to try a newer or older version of the TelORB Manager, do as
follows on the IO processor:

  cd /opt/telorb/codearchive/Unix_IDP/included/LM_D115-TelORBManager/jar/
  mv TelORBManager.LM_D115.R1U11.jar old_TelORBManager.LM_D115.R1U11.jar_old
                                                                  (Adjust R1U11)
  ftp 134.138.186.50
  cd /ipims_dicos/BS2/tbAD14lp7/DICOS_IDPG/Unix_IDP/TelORBManager_LM/jar
                                                              (Adjust tbAD14lp7)
  bin
  get TelORBManager.LM_D115.R1V11.jar
  bye
  chmod 770 TelORBManager.LM_D115.R1V11.jar                       (Adjust R1V11)
  cd /opt/telorb/codearchive/Unix_IDP/included/LM_D115-TelORBManager
  gedit MI_attributes&               (Change version to new version, e.g. R1V11)
  /opt/telorb/codearchive/iom_scripts/TelORBManager -alarms&
                                                          (Start TelORB Manager)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

News in TelORB Manager 1.1
In the connect field, you can type:
134.138.186.101                       (Connect to 134.138.186.101 on port 7111)
134.138.186.101:9000                  (Connect to 134.138.186.101 on port 9000)
134.138.186.101:134.138.185.102       (Connect to either of the two IP addresses
                                       on port 7111)
134.138.186.101:9000:134.138.186.102:9001     (Connect to port 9000 on the first
                                               IP address or 9001 on the second)

Note: It is the CosNamingResponderPort one must connect to. This must be
configured in the epct file.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Memory Usage and DBN Memory Usage presented in the TelORB Manager
 (Updated: 2003-12-11 for TSP 4.0)

On the Advanced "Processors" card in the TelORB Manager there is memory usage
information for each of the TelORB processors in the system. This information
should be interpreted as follows:

Memory Usage:
  Shows the current memory usage of the selected processor.
  (Only process owned memory usage shown?)

Memory Alarm Level:
  Shows the current memory alarm level which can be changed in runtime by
  clicking on the box and entering a new memory alarm level, i.e. the level at
  which an alarm will be raised. If the Memory Usage goes above the specified
  limit, a Memory Usage Limit Exceeded alarm will be raised.

Load Regulation:
  Load Regulation is typically called by an application on entry, to determine
  whether there is sufficient capacity available to perform a task. If the CPU
  load rises above the specified load regulation level, applications, which use
  Load Regulation, will start to reject calls. The Load Regulation should never
  be set above the 75% default, but you can set it lower to provide lower
  latency times, or spare capacity for tasks such as backups and/or upgrades.
  (Note that Load Regulation is not currently supported on LinuxIntelPc
  processors, and thus this panel is greyed out for LinuxIntelPc.)

DBN Memory Share:
  Shows the percentage of the total memory available for use by the database.
  It also allows you to specify a new percentage level for the percentage of the
  processor's memory that is available for use by the DBN (see below).
  The default value is 80%.
  Specifying a new percentage level is a dangerous operation, unless you know
  what percentage of the memory is taken up by the code. If e.g. the code
  (without subscriber objects) occupies 12% of the physical memory and you set
  the DBN memory share higher than 87%, the system will perform a zone reload.
  The combination of DBN memory share and code memory share must never exceed
  99%. Since it is not easy to calculate the code memory share, the raising of
  the DBN memory share should only be performed with the consent and agreement
  of TSP support.
  (Note that the server side of the TelORB database, DBN, is not currently
  supported on LinuxIntelPc processors, and so this panel is greyed out for
  LinuxIntelPc.)

DBN Memory Usage:
  Shows what percentage of the memory available to the database is currently in
  use. This is for information only, but it allows you to see whether or not the
  settings for the DBN Memory Share are too low.
  (Note that the server side of the TelORB database, DBN, is not currently
  supported on LinuxIntelPc processors, and so this panel is greyed out on
  LinuxIntelPc.)

DBN Memory Alarm:
  The DBN Memory alarm level is shown, and the threshold can be set.
  More details can be found in the documention for the alarm "Too Much DBN Data"
  (Note that the server side of the TelORB database, DBN, is not currently
  supported on LinuxIntelPc processors, and so this panel is greyed out on
  LinuxIntelPc.)

Description of the alarm "Too Much DBN Data":
  The TelORB Manager allows you to see (and set) the percentage of each
  processor's memory that can be used by the database. When the usage of that
  reserved memory reaches the alarm level (also visible and settable), the alarm
  is raised as a Minor alarm. The alarm level is raised to Critical when usage
  reaches 99% of the available DBN memory because if the level rises to 100%,
  all create transactions will be aborted.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Prerequisites for the TelORB Browser
To be able to run the TelORB Browser from an IO processor, the following
directories (including related directories and files) must exist in the
following locations on the IO processor:

1. Directory /opt/jdk1.1.7B/                            (or other version)
2. Directory /home/telorb/visijars/
3. File /home/telorb/Examples/Locations
4. Directory /home/telorb/Examples/TelorbBrowserX.X/    (Fetched below)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Fetch the correct version of the TelORB Browser, if not already done
All TelORB Browser versions can be found at
/home/dicoshack/Hack/tools/ on the local EAB CW/OS lab net (e.g. from client
uabs31i1cxx).
The version that correponds to the TelORB release that is used should be copied
to directory /home/telorb/Examples/ on the IO processor(s) as described below.
Remember to adjust the TelORB Browser version to that of the TelORB Browser to
be fetched (see list below).

List of TelORB Browser versions and their corresponding TelORB releases:

- TelorbBrowser4.2 corresponds to TelORB release AD9.05.3.
- TelorbBrowser5.4 corresponds to TelORB releases AD11.4.1 and AD12.4.


Check if a packed version of the TelORB Browser of your choice exists:
  cd /home/dicoshack/Hack/tools/
  ls -l

Follow the instructions in step 1 or 2 below:
1. If the TelORB Browser to fetch is already packed in directory
   /home/dicoshack/Hack/tools/, do as follows:
  telnet toXio1                    (Log in to the IO processor to put e.g. the
                                    directory TelorbBrowser5.4 and its files on,
                                    e.g. IO processor 1. Adjust toX to valid
                                    TelORB system or use IP address)
  login: telorb                    (Type user name)
  Password:                        (Type password)

  mkdir /home/telorb/Examples      (Only if /home/telorb/Examples does not
                                    already exist)
  cd /home/telorb/Examples         (Go to directory Examples to fetch to on IO)
  ftp 134.138.186.xx               (Set up ftp to e.g. client uabs31i1c46. Use
                                    your own client)
  telorb                           (Log in as telorb user)
  psw                              (Type telorb password)
  bin                              (Enter binary transfer mode)
  cd /home/dicoshack/Hack/tools/   (Go to directory to fetch from)
  get TelorbBrowser5.4.tar         (Fetch tar file. Or get TelorbBrowser5.4.tgz)
  bye                              (Exit ftp)
  ls -l                            (Check that the tar file is received on IO)
  tar xf TelorbBrowser5.4.tar      (Extract tar file on current directory
                                    (Examples). Or tar zxf) TelorbBrowser5.4.tgz?)
  ls -l                            (Check that the directory TelorbBrowser5.4 is
                                    created)
  rm TelorbBrowser5.4.tar          (Remove the tar file from IO. Or
                                    rm TelorbBrowser5.4.tgz)
  exit                             (Exit from toXio1)

  Repeat the sequence above for the other IO processor, if desired.


2. If the TelORB Browser to fetch is not packed, pack the TelORB Browser
   directory contents into a tar (or tgz) file and put it elsewhere (e.g.
   /home/dicostest/tosFiles/toX/) as follows:
  cd /home/dicoshack/Hack/tools/   (Go to the location where all versions of the
                                    TelORB Browser are located from e.g. a local
                                    shell)
  tar cf /home/dicostest/tosFiles/toX/TelorbBrowser5.4.tar TelorbBrowser5.4
                                   (Adjust toX to valid TelORB system)
  cd /home/dicostest/tosFiles/toX/ (Adjust toX to valid TelORB system)
  ls -l                            (Check that tar file "TelorbBrowser5.4.tar"
                                    has been created)
  telnet toXio1                    (Log in to the IO processor to put e.g. the
                                    directory TelorbBrowser5.4 and its files on,
                                    e.g. IO processor 1. Adjust toX to valid
                                    TelORB system or use IP address)
  login: telorb                    (Type user name)
  Password:                        (Type password)

  mkdir /home/telorb/Examples      (Only if /home/telorb/Examples does not
                                    already exist)
  cd /home/telorb/Examples         (Go to directory Examples to fetch to on IO)
  ftp 134.138.186.xx               (Set up ftp to e.g. client uabs31i1c46. Use
                                    your own client)
  telorb                           (Log in as telorb user)
  psw                              (Type telorb password)
  bin                              (Enter binary transfer mode)
  cd /home/dicostest/tosFiles/toX/ (Go to directory to fetch from on WS)
                                   (Adjust toX to valid TelORB system)
  get TelorbBrowser5.4.tar         (Fetch tar file)
  bye                              (Exit ftp)
  ls -l                            (Check that the tar file is received on IO)
  tar xf TelorbBrowser5.4.tar      (Extract tar file on current directory
                                    (Examples))
  ls -l                            (Check that the directory TelorbBrowser5.4 is
                                    created)
  rm TelorbBrowser5.4.tar          (Remove the tar file from IO)
  exit                             (Exit from toXio1)

  Repeat the sequence above (from telnet) for the other IO processor, if desired.

  rm TelorbBrowser5.4.tar          (Remove the tar file from .../tosFiles/toX/)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start the TelORB Browser
- Log in to the IO processor which will run the TelORB Browser, e.g.:
  telnet toXio1                    (Log in to IO processor. It is possible to
                                    use any IO processor within the EAB CW/OS
                                    lab Pink LAN. Adjust toX to valid TelORB
                                    system or use IP address)
  login: telorb                    (Type user name)
  Password:                        (Type password)

- Start TelORB Browser's initial window "Connect" (Use correct version of TelORB
  Browser in path below):
  /home/telorb/Examples/TelorbBrowser5.4/bin/TelorbBrowser &

- In window "Connect", fill in the IP address of TelORB processor 1, either over
  EthA or EthB, e.g.:
  Hostname : 134.138.xx.101       (The last IP-address specified as
                                   the DorbIIOPHostName-value in the epct file
                                   decides the TelorbBrowser interface - not
                                   the hostname value)

- In window "Connect", click "Ok".


To start the TelORB Browser in your work environment at the EAB CW/OS lab (i.e.
not on one of the IO processors), do as follows:
  cd /home/dicoshack/Hack/tools/  (Go to where the TelORB Browsers are located)
  ls -l                           (Select TelORB Browser to use, e.g.
                                   TelorbBrowser4.2 for AD9.05)
  TelorbBrowser4.2/bin/TelorbBrowser &   (Start TelORB Browser)
    or
  /home/dicoshack/Hack/tools/TelorbBrowser4.2/bin/TelorbBrowser &

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start alarm & notification window for the TelORB Browser
These guidelines describe two ways of starting the alarm & notification
window, i.e. either by using the TelORB Browser (TelORB Browser 4.0 or later)
or via telnet.

Start alarm & notification window via TelORB Browser
- Use TelORB Browser - Processor List: Click on "Show Alarms", which opens
  window "Alarms".
- In the opened window, click "Show Filtering", then click "Cancel subscription"
  and then click "Subscribe".


Start alarm & notification window via telnet
telnet 134.138.70.101 7111        (IP address of TelORB processor 1, to EthA)
NamingBrowser/Run _IOR_ &         (Opens window "Corba Naming Browser")
                                  (IOR = IOR from line above,
                                   including "IOR:")
Consumer/Run &                    (Opens window "OaM Test")
exit                              (Exit from IO processor, if desired)

Either
  Click on the bullet for "telorb" in window "Corba Naming Browser".
  Click on the bullet for "alarm" in window "Corba Naming Browser".
  Click on the "AlarmHandler" text string in window "Corba Naming Browser"
  to get IOR for the alarm handler.
  Insert the IOR for the alarm handler in the correct place in window
  "OaM Test".
  Click on the "NotificationHandler" text string in window "Corba Naming
  Browser" to get IOR for the notification handler.
  Insert the IOR for the notification handler in the correct place in window
  "OaM Test".
or
  Get the IORs for alarm handler and notification handler from either
  TelORB processor 1 or 2 log files (from when building the system or
  from a zone reload) ("IOR_PRINT = 1" must be set in the "epct" file):
  cd /home/telorb/tor3/consolelogs/
  emacs log1&
  Insert the IORs for alarm handler and notification handler in their
  respective places in window "OaM Test".

Click on "Subscribe" in  window "OaM Test".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints for the TelORB Manager
From TelORB R14:
If you see a dialog box "<doing something> : System Error", it is probably a sign
that the TelORB Manager has timed out and that something is hung in TelORB.
This is bad, but at least now the rest of the TelORB manager functions are still
available.

-  -  -  -  -  -  -  -  -

The "Live Alarm Display" in the TelORB Manager has a button for manually
removing alarms which are not automatically removed when an error in the system
is fixed.
Note that the TelORB Manager is NOT the official GUI interface for receiving
alarms. The Node Management "Live Alarm Display" should be used!

-  -  -  -  -  -  -  -  -

The following problem was detected for TelORB Manager, version 2m.
I issued trouble report UABtr06481 for this.

If it is not possible to start the TelORB Manager from an IO processor and the
following error message is received, then look at your DISPLAY variable, and
check that it is set to a setting that is both correct and reachable from where
you are running the TelORB Manager:

/opt/telorb/codearchive/iom_scripts/TelORBManager -alarms&
[1] 17721
[telorb@to28io1 loadingGroup01_1]$ Visibroker 5.0 ORB plugin successfully
initiated
Problem with constructor javax.swing.plaf.FontUIResource and args {Dialog,0,12}
:  and types {class java.lang.String,int,int} :
java.lang.reflect.InvocationTargetException
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:993)
        at javax.swing.UIDefaults$ProxyLazyValue.createValue(UIDefaults.java:663)
        at javax.swing.UIDefaults.get(UIDefaults.java:145)
        at javax.swing.MultiUIDefaults.get(MultiUIDefaults.java:46)
        at javax.swing.UIDefaults.getFont(UIDefaults.java:223)
        at javax.swing.UIManager.getFont(UIManager.java:456)
        at javax.swing.LookAndFeel.installColorsAndFont(LookAndFeel.java:90)
        at javax.swing.plaf.basic.BasicPanelUI.installDefaults(BasicPanelUI.java:51)
        at javax.swing.plaf.basic.BasicPanelUI.installUI(BasicPanelUI.java:42)
        at javax.swing.JComponent.setUI(JComponent.java:322)
        at javax.swing.JPanel.updateUI(JPanel.java:107)
        at javax.swing.JPanel.<init>(JPanel.java:67)
        at javax.swing.JPanel.<init>(JPanel.java:97)
        at se.ericsson.TelORBManager.MainFrame.<init>(MainFrame.java:47)
        at se.ericsson.TelORBManager.Connection.main(Connection.java:567)
Exception in thread "main" java.lang.NoClassDefFoundError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:120)
        at
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:58)
        at java.awt.Window.<init>(Window.java:188)
        at java.awt.Frame.<init>(Frame.java:315)
        at java.awt.Frame.<init>(Frame.java:262)
        at javax.swing.JFrame.<init>(JFrame.java:141)
        at se.ericsson.TelORBManager.MainFrame.<init>(MainFrame.java:49)
        at se.ericsson.TelORBManager.Connection.main(Connection.java:567)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints for the TelORB Browser
- Sometimes it is necessary to click on "Cancel subscription" and thereafter
  "Subscribe" in the alarm & notification window to get it active.

- If the TelORB Browser window(s) do not disappear when quitting the TelORB
  Browser, kill the process(es) that starts with the following line:
    /usr/java1.1/bin/../bin/sparc/native_threads/java -classpath /home/telorb/Examp

The instructions below are valid for TSP 4.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions (Adjust xx and yy to valid ethernet network in the command lines below.) Start TelORB processor load viewer in TSP 4.0 Clusterware & OS on one of the IO processors: /opt/telorb/codearchive/iom_scripts/win -th 172.16.0.9 -th 172.16.8.9 -th 172.16.0.137 -th 172.16.8.137 -n -s & (Adjust the IP addresses to those valid for the Dicos processor loaders) or /opt/telorb/codearchive/iom_scripts/win -th 172.16.100.109 -th 172.17.100.109 -th 172.16.100.111 -th 172.17.100.111 -n -s & (Adjust the IP addresses to those valid for the Dicos processor loaders) or /opt/telorb/codearchive/iom_scripts/win -th 172.16.100.109 -th 172.17.100.109 -th 172.16.101.109 -th 172.17.101.109 -n -s & (Adjust the IP addresses to those valid for the Dicos processor loaders) Start TelORB processor load viewer in TSP 4.0 Clusterware & OS on a local workstation: source /ipims_dicos/BS2/tbAD14p3/IP_CONF_INFO/EnvSettings source /ipims_dicos/BS2/tbTEST1.3/IP_CONF_INFO/EnvSettings setenv DISPLAY 134.138.186.xx:0.0 (Set IP address of the WS to display on) win -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n -s & (no line break) Start TelORB processor load viewer in TelORB R14 on one of the IO processors: /opt/telorb/codearchive/iom_scripts/win -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n -s & (no line break) Start TelORB processor load viewer in TelORB R13 on one of the IO processors: /opt/telorb/codearchive/Unix_IDP/Win_LM/bin/Win.LM_MD45.R1H02.solaris -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n -s & (no line break) Start TelORB processor load viewer in TelORB AD9.05.3 (patch 25) on one of the IO processors: /opt/telorb/tools/IDP_MD15-Unix/LM_MD45-Win/bin/Win.LM_MD45.R1E01.solaris -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n -s & (no line break) From any of the IO processors: win -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n &

Run TelORB processor load viewer from e.g. IO processor 1
The TelORB processor load viewer software (Win) is part of the IO tools package
which exists on the IO processors at /opt/telorb/tools/ (/toX/toXio1/telorb/tools/ from tos1/tos2).

telnet toXio1                      (Log in to the IO processor to start the
                                    TelORB processor load viewer on, e.g. IO1.
                                    Adjust toX to valid TelORB system or use IP
                                    address)
login: telorb                      (Type user name)
Password:                          (Type password)

Either
/opt/telorb/tools/IDP_MD15-Unix/LM_MD45-Win/bin/Win.LM_MD45.R1G01.solaris -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n -s &
                                   (Adjust R1G01 to valid version of Win)
                                   (Adjust xx and yy to EthA and EthB addresses,
                                    respectively)
                                   (-n = show the load percentage)
                                   (-s = do not update the window smoothly)
 or (if path set?)
win -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n &
                                   (Adjust xx and yy to EthA and EthB addresses,
                                    respectively)
exit

Start TelORB processor load viewer in R13 from the official location:
/opt/telorb/codearchive/Unix_IDP/Win_LM/bin/Win.LM_MD45.R1H02.solaris -th 134.138.xx.101 -th 134.138.yy.101 -th 134.138.xx.102 -th 134.138.yy.102 -n -s &

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Run TelORB processor load viewer locally (from your own machine, e.g. client uabs31i1c47)
/ipims_dicos/ipims_dicos10/dists/TelORB-AD7.00/system/runtime/IDP_MD15-Unix/LM_MD45-Win/bin/Win.LM_MD45.R1B02.solaris -th 134.138.70.101 -th 134.138.74.101 -th 134.138.70.102 -th 134.138.74.102 -n -s &

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
If the TelORB processor load viewer window comes up and shows "No connection",
there may be a problem with the TelORB processor where the IDP "IDP/DUO2" is
running. Since the process for "IDP/DUO2" is central, static, unique it is
only running on one processor. Try to run the command string, e.g. 
/ipims_dicos/ipims_dicos10/dists/TelORB-AD7.00/system/runtime/IDP_MD15-Unix/LM_MD45-Win/bin/Win.LM_MD45.R1B02.solaris -th 134.138.70.101 -n -s &
i.e. towards only one TelORB processor at a time.
If this does not work, check which TelORB processor that contains "IDP/DUO2"
(e.g. P1) and reload that TelORB processor. "IDP/DUO2" will be moved to another
TelORB processor (e.g. P2). Then try to start the TelORB processor load viewer
once more.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Processor load viewer color info
The load viewer shows the load priorities in three different colours as follows:

TelORB processor with TelORB OS:

Yellow = Low (C) priority jobs (E.g. O&M jobs such as backup creation and
executing transactions received from primary zone in standby zone).
Green = Normal (B) priority jobs (E.g. traffic).
Red = High (A) priority jobs (E.g. operating system jobs such as database
transaction recovery).


TelORB processor with Linux OS:

Yellow = Low priority jobs (E.g. nice, see `man nice').
Green = Normal priority jobs.
Red = Execution time in Linux kernel.

Note: This section is no longer valid, since the DNS settings are nowadays set
      in the epct configuration file.
      This section will therefore soon be removed, but is kept some time for
      reference reasons.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

General

DNS is used to set up TelORB's contact with the outside world, e.g. to make
it possible to send out alarms and notifications (works anyway?) and to specify
the IP address of the RMS so that "TelORB" knows which RMS to ask for HW alarms.

To get the DNS values to be set, check the following file on both IO processors:
more /etc/hosts

== == == == == == == == == == == == == == == == == == == == == == == == == ==

How to set DNS values for IO processors in TelORB system to3

To get the DNS values for the rest of the TelORB systems, see further down.

Use TelORB Browser - Processor List: Click on "DNS" which opens window
                                     "Domain Name System".

to3io1              (Enter name of IO1 in upper text field)
134.138.187.20      (Enter IP address of to3io1 in lower text field)
Click on "addHost"

to3io1              (Already entered in upper text field)
134.138.70.25       (Enter IP address of to3io1i2, i.e. EthA - IO1, in lower text field)
Click on "addIP"

to3io1              (Already entered in upper text field)
134.138.74.25       (Enter IP address of to3io1i3, i.e. EthB - IO1, in lower text field)
Click on "addIP"

to3io2              (Enter name of IO2 in upper text field)
134.138.187.21      (Enter IP address of to3io2 in lower text field)
Click on "addHost"

to3io2              (Already entered in upper text field)
134.138.70.26       (Enter IP address of to3io2i2, i.e. EthA - IO2, in lower text field)
Click on "addIP"

to3io2              (Already entered in upper text field)
134.138.74.26       (Enter IP address of to3io2i3, i.e. EthB - IO2, in lower text field)
Click on "addIP"

== == == == == == == == == == == == == == == == == == == == == == == == == ==

How to set DNS values for RMS in TelORB system to3

If an alarm box, i.e. Knuerr RMS, is used in the TelORB system, also set the
IP address of the Knuerr RMS as follows (if not, continue with setting DNS
values for AXmp in the next section):

RMS                 (Enter "RMS" in upper text field. (The value "RMS" is
                     already set in the epct file, i.e. RMS_IP_ADDRESS = "RMS"))  
134.138.82.22       (Enter the IP address of the Knuerr RMS to be used in lower
                     text field)
Click on "addHost"

Quit window "Domain Name System".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

How to set DNS values for AXmp in TelORB system to10

If e.g. two AXmp boxes (for SS7) is used in the TelORB system, also set the
IP addresses of the AXmp boxes as follows (if not, quit window "Domain Name
System"):

to10s7c1            (Enter "to10s7c1" (AXmp1) in upper text field. (The value
                     "to11s7c1" is already set in the epct file, i.e.
                     AXMP_ADDRESSES = "to10s7c1:9977,to10s7c2:9977"))  
134.138.61.23       (Enter the IP address of AXmp1 for EthA in lower text field)
Click on "addHost"

to10s7c1            (Already entered in upper text field)
134.138.62.23       (Enter the IP address of AXmp1 for EthB in lower text field)
Click on "addIP"

to10s7c2            (Enter "to10s7c2" (AXmp2) in upper text field. (The value
                     "to10s7c2" is already set in the epct file, i.e.
                     AXMP_ADDRESSES = "to10s7c1:9977,to10s7c2:9977"))  
134.138.61.24       (Enter the IP address of AXmp2 for EthA in lower text field)
Click on "addHost"

to10s7c2            (Already entered in upper text field)
134.138.62.24       (Enter the IP address of AXmp2 for EthB in lower text field)
Click on "addIP"

Quit window "Domain Name System".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DNS settings for TelORB system to6

to6io1			to6io2			RMS
  134.138.187.29	  134.138.187.30	  134.138.82.22
  134.138.76.25		  134.138.76.26
  134.138.77.25		  134.138.77.26

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DNS settings for TelORB system to7

to7io1			to7io2			RMS
  134.138.187.32	  134.138.187.33	  134.138.82.22
  134.138.67.25		  134.138.67.26
  134.138.68.25		  134.138.68.26

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DNS settings for TelORB system to8

to8io1			to8io2			RMS
  134.138.187.35	  134.138.187.36	  134.138.68.222
  134.138.67.225	  134.138.67.226
  134.138.68.225	  134.138.68.226

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DNS settings for TelORB system to10

to10io1			to10io2			RMS
  134.138.187.47	  134.138.187.48	  134.138.62.22
  134.138.61.25		  134.138.61.26
  134.138.62.25		  134.138.62.26

to10s7c1 (AXmp1)	to10s7c2 (AXmp2)
  134.138.61.23		  134.138.61.24
  134.138.62.23		  134.138.62.24

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DNS settings for TelORB system to11

to11io1			to11io2			RMS
  134.138.187.44  	  134.138.187.45	  134.138.62.222
  134.138.61.225	134.138.61.226
  134.138.62.225	  134.138.62.226

to11s7c1 (AXmp1)	to11s7c2 (AXmp2) (to11s7c2 not yet installed)
  134.138.61.40		  134.138.61.41
  134.138.62.40		  134.138.62.41

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DNS settings for TelORB system to14

to14io1                 to14io2                 RMS
  134.138.187.54          134.138.187.55          134.138.58.22
  134.138.57.25           134.138.57.26
  134.138.58.25           134.138.58.26

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DNS settings for TelORB system to15

to15io1                 to15io2                 RMS
  134.138.187.56          134.138.187.57          134.138.60.22
  134.138.59.25           134.138.59.26
  134.138.60.25           134.138.60.26

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
To remove a DNS setting, the value has to be written into the appropriate text
field, and thereafter the button "delHost" or "delIP" is to be clicked upon.

Also see DUCK server, DNS & FileServerInterpreter.

Warning
Never, ever, activate another backup version without zone reloading from it!

If the activated backup version is not zone reloaded from, any processor
reload may fail.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

General
The following is stored when creating a backup: 
- The TelORB database.

The following is stored when creating a backup: 
- The TelORB database.
- The bootLoadTable.0 file for each TelORB processor.

As long as there is one functioning IO processor, TelORB can be backed up.

Possible backups for TelORB R14 are:
1. Manual backup (known by SoftwareVersion and BackupMO)
2. Scheduled backups (known by SoftwareVersion and BackupMO)
3. Scheduled remotesynch backups (known by SoftwareVersion and BackupMO)
4. Manual remotesynch backups (known by SoftwareVersion and NRC)
5. Manual reconciliation backups (known by SofwareVersion and NRC)
Only the SoftwareVersion is aware of all possible backups.
                                            (Source: TR UABtr03943)

Note: In R13, if a removal/addition of a TelORB processor has been performed,
      do not attempt to reload the system from a backup that was created before
      the removal/addition. This will result in cyclic zone reloads.
      (TR.1754 issued)

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Changes in the backup handling in TSP 5.0  (E-mail from uabnasl, 2003-11-11)
-----------------------------------------
This is just an information mail, you don't need to act on it.

I have made some changes in the backup area (backups on DBN, that is).
I have removed the old 'activeVersion' file and replaced it with a soft link
called 'active':

    <path>/axe/loadingGroup01/backups/active 

The 'active' soft link will always point to the active backup, for instance:

    <path>/axe/loadingGroup01/backups/active -> myBackup

epct will initially set the 'active' soft link to '..' so that the path

    <path>/axe/loadingGroup01/ProcessorX/bootLoadTable.0 

is valid from the start. 

This big advantage with the 'active' soft link is that the eptftp program on
the IO processors can be completely removed since the path to the active backup
will always be the same. 

My changes have been delivered to tbAD15/devenv4.0. 

Regards
/Stefan


Changes in the backup handling in TSP 5.0
-----------------------------------------
(Excerpt from e-mail from uabnasl, 2003-11-??)

This mail concerns users of Vega and vmware.
  :
  :
In TSP5 we no longer copy the bootloadtables from the actual backup to the
processor directories under the loading group. Thus, after a backup you cannot
use the same bootloadtable to start a "loader" processor, you would then
initiate an initial start again! To avoid having to specify a different
bootloadtable path after a backup, eprun and eplinuxrun now always use the
bootloadtable pointed out by the soft link (see my previous email)

  .../loadingGroup01/backups/active/ProcessorX/bootLoadTable.0

thus always using the "latest" bootloadtable but with a fixed path.
And I have chosen to hide the use of the active link inside eprun and
eplinuxrun instead of forcing everyone to explicitly write a
bootloadtable path including the active link.

Regards
/Stefan 

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Create a backup
- Use TelORB Browser - Processor List: Click on "Software Backup".

- In the opened window "Software Backup", enter the name of the backup version
  to be created and then click on "Add".

- Check that notification "Backup started" is received.

- Wait until notification "Backup Succeeded" is received.

- Click on "Refresh" to verify that the created backup version is active.

- Quit the window "Software Backup".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
The software backup files are stored on both IO processors as follows:
  cd /opt/telorb/axe/loadingGroup01_1/backups/  (On IO1)
  cd /opt/telorb/axe/loadingGroup01_2/backups/  (On IO2)

- It should be possible to create a software backup version when one of the IO
  processors are unavailable.

- If one of the IO processors are rebooted/crashes during a backup the backup
  creation should be terminated.

- If one of the ethernet switches are unavailable when a backup is started, the
  backup creation should be successful to both IO processors (verified 991109).

- Only letters (Aa-Zz), numbers (0-9), and the characters underscore (_),
  colon (:), hyphen (-) and full stop (.) are allowed in a backup name.
  (Source TR.1423.)

- Before building and initial loading a TelORB system, it is a good idea to
  remove everything below the directories
  /opt/telorb/axe/loadingGroup01_1 and /opt/telorb/axe/loadingGroup01_2
  on the IO processors. The reason for this is to keep the memory usage on a low
  level by removing previously used files that origins from older releases.
  All directories and files below loadingGroup01_x will be created when building
  the TelORB system (epct).
  Log in to IO processors 1 and 2, respectively and give the following command
  when standing on directory loadingGroup01_1 and loadingGroup01_2,
  respectively:
    rm -r *

- It is possible to copy the complete loadingGroup01_1 directory to the
  loadingGroup01_2 directory and vice versa if e.g. loadingGroup01_2 is
  corrupted. Remember to rename the copied directory so that loadingGroup01_1
  always is located on IO1 and loadingGroup01_2 on IO2.

- To stop an ongoing backup creation in a test environment with a valid
  previous backup version, reload a TelORB processor.

- After initial load, the file activeVersion (below
  /opt/telorb/axe/loadingGroup01_x/backups/) does not exist on any of the
  IO processors.

- To check the size of e.g. a backup, i.e. the size of a backup directory and
  its underlying directories and files, go to directory
    /opt/telorb/axe/loadingGroup01_1/backups/
  or
    /opt/telorb/axe/loadingGroup01_2/backups/
  and enter command
    du -sk _backupname_
  The result is given in kilobytes.

General
 (Updated: 2003-09-11)

The TSP Reference Application is a traffic simulator to be used in TelORB
systems and is developed at EAB-CCND.

Normal CORBA from GUI to static C++ process is tested when using the TSP
Reference Application (uabblom, 2003-10-21).

For a description of the TSP Reference Application, see The TSP Reference Application.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Examples of a TSP Ref App epct file
 (Updated: 2003-11-11)

Below is an example which can be used for a Dicos-only, a Linux-only or a mixed
system.
The mix of De2SubPool and De2SubNonCoLocatedPool on different TelORB processors
gives different traffic intensity on the processors. 
Start C++ and Java traffic for both "Co-located" and "Non co-located" traffic.
(Proc_m0_s9 and Proc_m1_s9 are used as Dicos loaders, but may be used as
ordinary Linux processors in a Linux-only system.)


SOFTWARE
	IDP/DEM101;	// Demo2_IDP, Optional

PROCESSOR Proc_m0_s3 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool; 
PROCESSOR Proc_m0_s5 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;
PROCESSOR Proc_m0_s7 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;
PROCESSOR Proc_m0_s9 ALSO IN De2CoordPool,De2GwPool,De2UnixAccessPool,De2VipAccessPool;
PROCESSOR Proc_m0_s11 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;
PROCESSOR Proc_m0_s13 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;
PROCESSOR Proc_m0_s15 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;
PROCESSOR Proc_m0_s17 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;
PROCESSOR Proc_m0_s19 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;
PROCESSOR Proc_m0_s21 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;
PROCESSOR Proc_m0_s23 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;

PROCESSOR Proc_m1_s9 ALSO IN De2CoordPool,De2GwPool,De2UnixAccessPool,De2VipAccessPool;
PROCESSOR Proc_m1_s11 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;
PROCESSOR Proc_m1_s13 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;
PROCESSOR Proc_m1_s15 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;
PROCESSOR Proc_m1_s17 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;
PROCESSOR Proc_m1_s19 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;
PROCESSOR Proc_m1_s21 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool;
PROCESSOR Proc_m1_s23 ALSO IN De2TGPool,De2DisPool,De2PopPool,De2SubNonCoLocatedPool;


Note:
- The pool De2SubNonCoLocatedPool must always be located on at least one TelORB
  processor to avoid epct errors when building the system.
  Note: In the new TSP Ref App, De2SubNonCoLocatedPool is replaced by
  De2SubLinuxPool, see below. 

- The pools De2SubPool and De2SubNonCoLocatedPool cannot be co-located on the
  same TelORB processor (this is possible when doing epct, but will lead to
  errors in runtime).

- It is also possible to locate De2SubNonCoLocatedPool on one of the TelORB
  processors and then locate either De2SubPool or De2SubNonCoLocatedPool on the
  rest of the processors.

- The pools De2GwPool and De2UnixAccessPool are not being used by TSP Ref App,
  but must be allocated to avoid epct errors.

- The pool De2CoordPool must be located on two of the TelORB processors,
  preferably on the Dicos loaders, if any. In a Linux-only system, De2CoordPool
  can be located on any two processors.

- De2VipAccessPool handles incoming VIP traffic.
  If VIP traffic should be executed in the system, the pool De2VipAccessPool
  can be located on the TelORB processors where you want incoming VIP traffic.
  To not have to adjust the epct file regarding which processors having incoming
  VIP traffic, you can allocate De2VipAccessPool to all processors in the system
  (even to the Dicos loaders, if desired). In this case, you can configure
  incoming VIP traffic on any of the processors. If you for some reason do not
  want incoming VIP traffic on certain processors, do not allocate
  De2VipAccessPool to these processors.
  De2VipAccessPool does not act as a load sharer.
  If VIP traffic should not be executed in the system, the pool De2VipAccessPool
  can be located on the Dicos loaders, if any. In a Linux-only system,
  De2VipAccessPool can be located on any two processors. (Also see uabkrni's
  contribution below.)

- In the new TSP Ref App, De2SubNonCoLocatedPool is replaced by De2SubLinuxPool.
  De2SubLinuxPool should normally be located on at least two Linux processors.
  De2SubLinuxPool must always exist in the system, no matter if Linux processors
  exist or not. If not, epct will fail.
  When populating e.g. 50000 database objects, 100000 database objects will
  actually be created, i.e. 50000 "Dicos" objects and 50000 "Linux" objects.
  If you want to have only e.g. 100000 "Dicos" database objects, i.e. no "Linux"
  database objects, locate both De2SubPool and De2SubLinuxPool on only Dicos
  processors and populate 50000 objects.
  For an even population in a mixed system with ~50% Dicos processors and ~50%
  Linus processors, locate De2SubPool on all Dicos processors and
  De2SubLinuxPool on all traffic handling Linux processors.
  In a DicosMax system, locate De2SubLinuxPool on all Dicos processors and none
  on the Linux traffic processor, if any.
  If you only want to populate some of the processors, locate De2SubPool and
  De2SubLinuxPool on the selected processors.
    Info from Niclas Blomgren, 2005-01-31:
    På förkommen anledning så vill jag informera om följande:
    De2SubPool och De2SubLinuxPool funkar på båda OSen. Namnen är missvisande
    och skall bytas någon gång när jag har tid. När man populerar en subscriber
    så skapas en Subscriber POT instans OCH en SubscriberLinux POT instans.
    Även här är namnen missvisande. Så har man tex ett 40 proc system med enbart
    2 linux TPar så är det inte så lyckat att populera 10 milj subskribers om
    man bara lagt De2SubLinuxPoolen på linux TParna. Å andra sidan så blir
    traffiken missvisande om man lägger De2SubLinux på Dicos TPar och man kör
    linux traffik eftersom den då mestadels körs på Dicos.
    Lösningen är att tillåta separat populering av Subscriber och
    SubscriberLinux men det har jag givetvis inte tid att fixa.
    Slutsats: Konfigurera ett mixat-system med lika många Dicos som Linux TPar
    och lägg De2SubLinuxPool på Linuxarna och De2SubPool på Dicosarna. 

Also consider the following (uabkrni's contribution):
- De2SubPool must exist in the system. When populating, it is processors with
  this pool that are "populated".

- Database accesses is now done from processors also with
  De2SubNonCoLocatedPool. Previously, when Linux processors had no database,
  De2SubNonCoLocatedPool was intended for those Linux processors. Still the POTs
  are located to processors with De2SubPool and thus De2SubNonCoLocatedPool must
  "fetch info" from those processors. Traffic on De2SubNonCoLocatedPool will
  therefore generate some load also on processors with De2SubPool.

- It is a good idea to allocate De2SubPool to either Dicos or Linux processors
  and De2SubNonCoLocatedPool to the other group (i.e. Dicos or Linux) in a mixed
  system. In this way it is possible to adjust the traffic load to the processor
  type so that both types get a reasonable load. (The same call intensity would
  normally generate a higher load on Linux than on Dicos.)

- De2VipAccessPool is used only when VIP traffic is running, but can be
  allocated to all processors (except possibly the loaders?) all the time, if
  desired. That is, it doesn't disturb when VIP is not active.
  (Michel var lite otydlig där tyckte jag.)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Nice set up for a two-Linux-processor-system in TSP 5
 (Updated: 2004-04-30)

  TSP Ref App traffic data
  ------------------------

    POPULATE:                    Size of Objects: 100 bytes
                                 Ranging from: 0    Ranging to: 10000

    RUN C++ Dicos traffic:       Update: 45%           Read: 45%
                                 Create/Delete: 9%    OP4:    1%  str=1000,10,5
                                 Intensity: 15 calls/sec
                                 Ranging from: 0    Ranging to: 10000
                                 Internal traffic

    JRUN Java Dicos traffic:     Update: 45%           Read: 45%
                                 Create/Delete: 10%    OP4:   0%  str=1000,10,5
                                 Intensity: 15 calls/sec
                                 Ranging from: 0    Ranging to: 10000
                                 Internal traffic

    RUN C++ Linux traffic:       Update: 45%           Read: 45%
                                 Create/Delete:  9%    OP4:   1%  str=1000,10,5
                                 Intensity: 15 calls/sec
                                 Ranging from: 0    Ranging to: 10000
                                 Internal traffic

    JRUN Java Linux traffic:     Update: 45%           Read: 45%
                                 Create/Delete: 10%    OP4:   0%  str=1000,10,5
                                 Intensity: 15 calls/sec
                                 Ranging from: 0    Ranging to: 10000
                                 Internal traffic

    Traffic load:
      ~14-26% load on IO1 and IO2.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Explanation of OP4 (The Aggressive Database Operation) and its parameters
 (Updated: 2004-04-30)

The three database operations (update, read and create/delete) which are
supported by the TSP Reference Application do not exercise the TelORB database
code very well.
The OP4 operation executes a more aggressive access towards the TelORB database,
which means that this operation exercises the DBN more heavily than the other
operations.

The operation performs multi-object transactions for randomly picked objects
from the cluster (i.e. NO co-location of processes and data). 

User guide:
Give OP4 a value larger than 0% and then set the following three parameters (OP4
Params):
- The first parameter, subSetSize, sets the number of objects involved in this
  operation. A low value increases the risk for locking conflicts to occur.
  (Specifies the number of objects of the total population which will be used
  for OP4 traffic. The maximum value is half of the total population.)
- The second parameter, maxTransactionSize, sets the maximum number of objects
  involved in each transaction. All objects involved in a transaction will be
  read at transaction start (to validate a checksum).
- The third parameter, maxNumberOfUpdates, sets the maximum number of objects to
  perform the update operation on. The create/delete operation does only occur
  randomly, but the chance increases when the maxNumberOfUpdates is low (the
  create/delete operation will be used for every transaction if
  maxNumberOfUpdates is set to two).

It is possible to run OP4 as telorb or IP-traffic.
Use OP4 for C++ traffic on Dicos and Linux processors.
Do not use OP4 for Java traffic yet!

A good way to see that OP4 operations are in progress, is to check that
'ExtraServiceObjects' are being created.

Example values for when the population range is from 0 to 100000:
 OP4 Params: 45000 (subSetSize), 10 (maxTransactionSize), 5 (maxNumberOfUpdates)
Note that the maximum value for subSetSize is half of the total population.

General
 (Updated: 2001-08-24)

DemoApp2000 is a traffic simulator to be used in TelORB systems and is developed
at EAB CW/OS.
For general DemoApp2000 documentation, see DemoApp2000.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DemoApp2000 pool configuration
 (Updated: 2002-08-28)

Valid for `TSP 4.0 Clusterware & OS' and later.

The pools for DemoApp2000 should be configured as follows in a system with
a mixture of Dicos processors and Linux processors:

  For two Dicos loader processors:
    PROCESSOR Proc_m0_s9 ALSO IN De2CoordPool,De2GwPool;

  For all Dicos non-loader processors:
    PROCESSOR Proc_mX_sY ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;

  For all Linux processors:
    PROCESSOR Proc_mX_sY ALSO IN De2SubNonCoLocatedPool;

  For two Dicos non-loader processors, if no Linux processors are used (do not
  execute Linux traffic in this case):
    PROCESSOR Proc_mX_sY ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool,De2SubNonCoLocatedPool;


Example of an epct file where the following applies:
  9 Dicos: m0_s7, m0_s9 (loader), m0_s15, m0_s17, m0_s19, m1_s9 (loader),
           m1_s11,m1_s19, m1_s21)
  9 Linux: m0_s3, m0_s5, m0_s11, m0_s13, m0_s21, m0_s23, m1_s13, m1_s15,
           m1_s23)

  SOFTWARE
	IDP/DEM101;	// Demo2_IDP, Optional

  PROCESSOR Proc_m0_s3 ALSO IN De2SubNonCoLocatedPool; 
  PROCESSOR Proc_m0_s5 ALSO IN De2SubNonCoLocatedPool;
  PROCESSOR Proc_m0_s7 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;
  PROCESSOR Proc_m0_s9 ALSO IN De2CoordPool,De2GwPool;
  PROCESSOR Proc_m0_s11 ALSO IN De2SubNonCoLocatedPool;
  PROCESSOR Proc_m0_s13 ALSO IN De2SubNonCoLocatedPool;
  PROCESSOR Proc_m0_s15 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;
  PROCESSOR Proc_m0_s17 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;
  PROCESSOR Proc_m0_s19 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;
  PROCESSOR Proc_m0_s21 ALSO IN De2SubNonCoLocatedPool;
  PROCESSOR Proc_m0_s23 ALSO IN De2SubNonCoLocatedPool;
  // Proc_m1_s5 used as File Server
  PROCESSOR Proc_m1_s9 ALSO IN De2CoordPool,De2GwPool;
  PROCESSOR Proc_m1_s11 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;
  PROCESSOR Proc_m1_s13 ALSO IN De2SubNonCoLocatedPool;
  PROCESSOR Proc_m1_s15 ALSO IN De2SubNonCoLocatedPool;
  //PROCESSOR Proc_m1_s17 ALSO IN De2SubNonCoLocatedPool;
  PROCESSOR Proc_m1_s19 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;
  PROCESSOR Proc_m1_s21 ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;
  PROCESSOR Proc_m1_s23 ALSO IN De2SubNonCoLocatedPool;

  //-------------------------------------------------------------
  // Info from Michel
  //-------------------------------------------------------------

  // For all Dicos loader processors:
  //PROCESSOR Proc_m0_s9 ALSO IN De2CoordPool,De2GwPool;

  // For all Dicos non-loader processors:
  //PROCESSOR Proc_mX_sY ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool;

  // For all Linux processors:
  //PROCESSOR Proc_mX_sY ALSO IN De2SubNonCoLocatedPool;

  // For two Dicos non-loader processors, if no Linux processors are used
  // (do not execute Linux traffic in this case):
  //PROCESSOR Proc_mX_sY ALSO IN De2TGPool,De2DisPool,De2SubPool,De2PopPool,De2UnixAccessPool,De2SubNonCoLocatedPool;


Old example valid for earlier releases
--------------------------------------

	SOFTWARE
		IDP/DEM101;	// Demo2_IDP, Optional

	PROCESSOR Processor1 ALSO IN De2CoordPool,De2GwPool;
	PROCESSOR Processor2 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;
	PROCESSOR Processor3 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor4 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor5 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;
	PROCESSOR Processor6 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;
	PROCESSOR Processor7 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor8 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor9 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;
	PROCESSOR Processor10 ALSO IN De2CoordPool,De2GwPool;
	PROCESSOR Processor11 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor12 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor13 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;
	PROCESSOR Processor14 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;
	PROCESSOR Processor15 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor16 ALSO IN De2SubPool,De2PopPool;
	PROCESSOR Processor17 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;
	PROCESSOR Processor18 ALSO IN De2TGPool,De2DisPool,De2UnixAccessPool;

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Traffic setup template
 (Updated: 2002-08-28)

The intention with this section, is to attach it to e.g. trouble reports, to
inform the reader about the traffic intensity. Adjust the example values to
those valid for your system.


C++ and Java traffic generated by DemoApp2000
---------------------------------------------
Range number    Ranging from    Ranging to    Object size (bytes)
1               0               100000        4
2               100001          200000        40
3               200001          400000        400

Telorb Traffic  C++
Ranging from =0    Ranging to =400000
Update=34%         Read=33%
Create/Delete=33%  OP4=0%
Intensity=200calls/sec
Load Control=false

NO Java Traffic!!!


Nice set up of C++ and Java traffic (co-located and non co-located traffic)
---------------------------------------------------------------------------
Valid for an 18 TelORB processor system (9 Dicos / 9 Linux) and gives a load
of ~77 % load on the Dicos processors and 35-50% load on the Linux processors.

  POPULATE:                    Size of Objects: 100 bytes
                               Ranging from: 0    Ranging to: 1000000

  RUN Co-located traffic:      Update: 45%             Read: 45%
      (Dicos traffic)          Create/Delete: 9%       OP4:   1%  str=100000,6,3
                               Intensity: 3000 calls/sec
                               Ranging from: 0    Ranging to: 1000000
                               (TelORB Traffic)

  JRUN Co-located traffic:     Update: 45%             Read: 45%
       (Dicos traffic)         Create/Delete: 9%       OP4:   1%  str=100000,6,3
                               Intensity: 150 calls/sec
                               Ranging from: 0    Ranging to: 1000000
                               (TelORB Traffic)

  RUN Non co-located traffic:  Update: 45%             Read: 45%
      (Linux traffic)          Create/Delete: 9%       OP4:   1%  str=100000,6,3
                               Intensity: 100 calls/sec
                               Ranging from: 0    Ranging to: 1000000
                               (TelORB Traffic)

  JRUN Non co-located traffic: Update: 45%             Read: 45%
       (Linux traffic)         Create/Delete: 9%       OP4:   1%  str=100000,6,3
                               Intensity: 100 calls/sec
                               Ranging from: 0    Ranging to: 1000000
                               (TelORB Traffic)


Explanation of OP4 (The Aggressive Database Operation) and its parameters
-------------------------------------------------------------------------
The three database operations (update, read and create/delete) which are
supported by DemoApp2000 do not exercise the TelORB database code very well.
The OP4 operation executes a more aggressive access towards the TelORB database,
which means that this operation exercises the DBN more heavily than the other
operations.

The operation performs multi-object transactions for randomly picked objects
from the cluster (i.e. NO co-location of processes and data). 

User guide:
Give OP4 a value larger than 0% and then set the following three parameters (OP4
Params):
- The first parameter, subSetSize, sets the number of objects involved in this
  operation. A low value increases the risk for locking conflicts to occur.
  (Specifies the number of objects of the total population which will be used
  for OP4 traffic. The maximum value is half of the total population.)
- The second parameter, maxTransactionSize, sets the maximum number of objects
  involved in each transaction. All objects involved in a transaction will be
  read at transaction start (to validate a checksum).
- The third parameter, maxNumberOfUpdates, sets the maximum number of objects to
  perform the update operation on. The create/delete operation does only occur
  randomly, but the chance increases when the maxNumberOfUpdates is low (the
  create/delete operation will be used for every transaction if
  maxNumberOfUpdates is set to two).

It is possible to run OP4 as telorb or IP-traffic.

A good way to see that OP4 operations are in progress, is to check that
'ExtraServiceObjects' are created.

Example values:
 OP4 Params: 100000 (subSetSize), 6 (maxTransactionSize), 3 (maxNumberOfUpdates)

Start Demo application in a TelORB system via TelORB Browser
 (Updated: 2001-11-14)

Start Demo application
Using the TelORB Manager:
- Select the "Home" card.
- Click the arrow and select "UAB Demo App".
- Click "Show".
- In the opened window "Demo Application", enter e.g. the following values:
    Operation:       0      (0=Create/Update, 1=Create/Delete,
                             2=Create/Update/Delete, 3=Bank (add and withdraw
                                                             to/from an account)
    Call Window:     20     (No. of co-existing calls)
    No. Subscribers: 700000 (No. of objects/subscribers)
    Tracing:         false  (false=?, true=?)
    Partitioning:    Enable (Enable=Enable partitioning for NetRed,
                             Disable=Disable partitioning for NetRed)
- Click on Start "Apply".

Stop Demo Application
- Click on Stop "Apply" in the window opened above.

Hide the window "Demo Application"
- Click "Hide" as described above when the "Show" button was clicked upon.

Hints
- When running the Demo application with Operation = 3 (Demo Bank application)
  and the balance becomes not equal to zero, then if the Demo Bank application
  is stopped and started again, it will start to calculate the account sum again
  and the result will still be not equal to zero and the Demo Bank application
  will automatically stop. To get around this, start the Demo application with
  another Operation value (not 3), stop it and then start the Demo Bank
  application again.

  It is only possible to have one traffic generator active, i.e. traffic is only
  generated from one TelORB processor. With the new DemoApp2000 application this
  will be changed so that traffic generation can take place in one, several or
  all TelORB processors.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Traffic setup template
 (Updated: 2001-11-14)

The intention with this section, is to attach it to e.g. trouble reports, to
inform the reader about the traffic intensity. Adjust the example values to
those valid for your system.

C++ traffic generated by DemoApp
--------------------------------
Operation:       0       (0=Create/Update, 1=Create/Delete,
                          2=Create/Update/Delete, 3=Bank
Call Window:     10      (No. of co-existing calls)
No. Subscribers: 2000000 (No. of objects/subscribers)
Tracing:         false

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
Check demo configuration data:
http://134.138.xx.101:5557/DBN/Classes/DeTG_Config  (Adjust xx to valid network
                                                     address)
                                                    (Enter any TelORB processor)

Select one of the following ways to start the Java Demo application:

- Start Java Demo application in a TelORB system via TelORB Browser
- Start Java Demo application on Vega

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start Java application in a TelORB system via TelORB Manager
 (Updated: 2001-11-14)

Start Java application
Using the TelORB Manager:
- Select the "Home" card.
- Click the arrow and select "UAB Java Demo App".
- Click "Show".
- In the opened window "Java Demo Application", enter e.g. the following values:
    Language:        Java   (It is also possible to run C++ traffic)
    Operation:       0      (0=Create/Update, 1=Create/Delete,
                             2=Create/Update/Delete, 3=Bank (add and withdraw
                                                             to/from an account)
    Call Window:     5     (No. of co-existing calls)
    No. Subscribers: 700000 (No. of objects/subscribers)
    Reporting Interval: 3000 (Number of milliseconds between each traffic
                              generation sequence)
    Tracing:         true  (false=no traffic generator report printouts from TG,
                            true=traffic generator report printouts from TG)
    Partitioning:    Enable (Enable=Enable partitioning for NetRed,
                             Disable=Disable partitioning for NetRed)
- Click on Start "Apply".

Stop Java Application
- Click on Stop "Apply" in the window opened above.

Hide the window "Java Demo Application"
- Click "Hide" as described above when the "Show" button was clicked upon.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Traffic setup template
 (Updated: 2001-11-14)

The intention with this section, is to attach it to e.g. trouble reports, to
inform the reader about the traffic intensity. Adjust the example values to
those valid for your system.

Java traffic generated by JavaApp
---------------------------------
Language:        Java    (C++ or Java)
Operation:       0       (0=Create/Update, 1=Create/Delete,
                          2=Create/Update/Delete, 3=Bank)
Call Window:     5       (No. of co-existing calls)
No. Subscribers: 2000000 (No. of objects/subscribers)
Reporting Interval: 3000 (Number of milliseconds between each traffic
                          generation sequence)
Tracing:         true    (false=no traffic generator report printouts from TG,
                          true=traffic generator report printouts from TG)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start Java Demo application on Vega
Open a shell (xterm) that has access to `ipims_dicos'.
cd /home/dicoshack/Hack/uabhte/tools
emacs bin/cssh.csh&
bin/cssh.csh idl/DemoMO.idl  (CorbaScript will be installed)

The following start and stop instructions are fetched from the file
bin/cssh.csh:

a=CORBA::Object("IOR:000000000000001449444c3a44656d6f2f44656d6f4d4f3a312e300000
000001000000000000003401010000100000003133342e3133382e3138342e32313600e88000001
400000000000002000f4834000000000000000000000001")
  or
a=CORBA::Object("IOR:000000000000001449444c3a44656d6f2f44656d6f4d4f3a312e300000
0000020000000000000034010100000f0000003133342e3133382e37342e31303200007a7600001
400000000000002000f48340000000000000000000000010000000000000034010100000f000000
3133342e3133382e37302e31303100007a7600001400000000000002000f4834000000000000000
000000001")

a.start(0,0,20,100,3000,true)

a.stop()

Ctrl-c                 (Exit)

General
This traffic overload generator is no longer being used. This section is kept as
a reference if Omed should be used in the future.

Omed is a traffic overload generator.
Omed consists of a traffic generator part and an application part.

Omed is started and stopped via the telnet interface as follows (an example):
  telnet 134.138.70.101 8200     (If the TG is located in TelORB Processor 1)
  help         (if needed)
  flags 0      (flags 0 = load regulation active ; flags 1 = load regulation
                passive)
  go 10000 300 (test site dependent)
  stat         (print statistics)
  rate 750     (increase the traffic rate (from 300) to 750)
  Check epct file regarding load regulation values.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Generate high traffic overload
Modify demo.epct and omed.epct respectively:
PROCESSOR Processor1 ALSO IN ApplicationPool;
PROCESSOR Processor2 ALSO IN ApplicationPool;
:
PROCESSOR Processor7 ALSO IN TrafficGeneratorPool;

PROCESSOR Processor1 ALSO IN OmedGeneratorPool;
PROCESSOR Processor2 ALSO IN OmedWorkPool;
:
PROCESSOR Processor7 ALSO IN OmedWorkPool;

Start Omed with the following values:
flags 1
go 10000 1000 (test site dependent)

Check epct file regarding load regulation values:
IpcOverloadRejectLevels = (100, 200, 5000)
IpcOverloadWarningLevels = (100, 200, 5000)
IpcOverloadAbortLevels = (400, 800, 100000)

General
TelORB processors 1 and 2 are always reloaded individually directly from the
file system on one of the IO processors (they do not load each other).
TelORB processors 3 and onwards are always loaded by either TelORB processor 1
or 2 (TelORB processors 3 and onwards do not access the file system during
loading).

The TelORB system can handle a zone reload where one of the TelORB processors
does not respond, i.e. the system can be reloaded with maximum one (1) TelORB
processor excluded. If more than one TelORB processor do not respond during a
zone reload, the complete zone reload will fail.

Note: In R13, if a removal/addition of a TelORB processor has been performed,
      do not attempt to reload the system from a backup that was created before
      the removal/addition. This will result in cyclic zone reloads.
      (TR.1754 issued)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 1: Check which backup version the system will reload from
Using the TelORB Manager:
- Use the "Backups/Upgrades" card: Click "Rescan" below the "Backups" heading.
- Below the "Backups" heading: Check which backup version that is active,
  (this is indicated with a red (A) symbol).
  The system will be reloaded from the active backup version.


Using the TelORB Browser:
- Click "Software Backup".
- In the opened window "Software Backup", check which backup version that is
  active.
  The system will be reloaded from the active backup version.


Step 2: Change active backup version, if desired
If the backup version that you want to reload from is not active, you must set
the desired backup version as active, i.e. do the following:

Using the TelORB Manager:
- Use the "Backups/Upgrades" card: Click "Rescan" below the "Backups" heading.
- Below the "Backups" heading: Mark the name of the backup version to be
  reloaded from and then click "Activate".
- Check that notification "Backup Reactivation Started" is received.
- Wait until notification "Backup Reactivation Succeeded" is received.
- Click "Rescan" to verify that the activated backup version is active.

Using the TelORB Browser:
- Click "Software Backup".
- In the opened window "Software Backup", click "Refresh" (not necessary).
- In the opened window "Software Backup", mark the name of the backup version
  to be reloaded from and then click "Activate".
- Check that notification "Backup Reactivation Started" is received.
- Wait until notification "Backup Reactivation Succeeded" is received.
- Click "Refresh" to verify that the activated backup version is active.
- Quit the window "Software Backup".


If a TelORB Manager/Browser is not available, or if the system is not up and
running, log in to both IO processors from two separate shells and do the
following:

- Check which backup versions that are available by looking at the backup names
  below directory
    cd /opt/telorb/axe/loadingGroup01_1/backups/    (IO1)
    ls -lrt
  or
    cd /opt/telorb/axe/loadingGroup01_2/backups/    (IO2) 
    ls -lrt 

- Change the name of the active backup version to the name of the desired
  backup version in the file "activeVersion" on both IO processors below
  the directories
    /opt/telorb/axe/loadingGroup01_1/backups/       (IO1)
  and
    /opt/telorb/axe/loadingGroup01_2/backups/       (IO2)
  
  Quite possibly it is important to keep the characters ^@ at the end of the
  only line in the file activeVersion, but this is not yet verified.

- The following is NOT valid for e.g. TSP 4 or later releases:
  Copy the bootLoadTable.0 files from each of the Processor directories of the
  desired backup on both IO processors to replace those of the equivalent
  Processor directories below the directory loadingGroup01_X, see below.
  Note: In AD11.4.1 and higher, it is only necessary to copy the file
  bootLoadTable.0 for TelORB processors 1 and 2 (of course, in both IO
  processors).

    On IO1:
      cd /opt/telorb/axe/loadingGroup01_1/
      cp backups/_Name_of_backup_to_reload_from_/ProcessorX/bootLoadTable.0 ProcessorX/
    The cp command should be entered for TelORB processors 1 and 2 (for AD11.4.1
    and higher) or all TelORB processors (for AD9.05.3 and before).

    On IO2:
      cd /opt/telorb/axe/loadingGroup01_2/
      cp backups/_Name_of_backup_to_reload_from_/ProcessorX/bootLoadTable.0 ProcessorX/
    The cp command should be entered for TelORB processors 1 and 2 (for AD11.4.1
    and higher) or all TelORB processors (for AD9.05.3 and before).

    An example for IO1, TelORB processor 1:
      cp backups/backup_name/Processor1/bootLoadTable.0 Processor1/

- Sometimes a reboot of both IO processors is necessary, but only if a change
  of loadingGroups has been done.

-  -  -  -  -  -  -

  The following commands can be entered if all ProcessorX directories should be
  updated with the bootLoadTable.0 file:
  telnet toXio1                    (Log in to IO processor 1. Adjust toX to
                                    valid TelORB system or use IP address)
  login: telorb                      (Type user name)
  Password:                          (Type password)

  cd /opt/telorb/axe/loadingGroup01_1
  foreach dd(Proc*)
  foreach? cp backups/_Name_of_backup_to_reload_from_/$dd/bootLoadTable.0 $dd
  foreach? end
  exit                             (Exit from toXio1)

  telnet toXio2                    (Log in to IO processor 2. Adjust toX to
                                    valid TelORB system or use IP address)
  login: telorb                      (Type user name)
  Password:                          (Type password)

  cd /opt/telorb/axe/loadingGroup01_2
  foreach dd(Proc*)
  foreach? cp backups/_Name_of_backup_to_reload_from_/$dd/bootLoadTable.0 $dd
  foreach? end
  exit                             (Exit from toXio2)


Step 3: Perform a zone reload
- Use TelORB Browser - Processor List: Click on "Zone Reload".
- In the opened window "No Name", click on "Zone Reload".

  or

- Type "Ctrl-c" and "Enter" in two or more TelORB processor consoles to stop
  the execution (not necessary in windows that show "ColspPromLoader::entering
  the while loop").
- Type "q" (and "q") in all stopped TelORB processor consoles to start the
  execution.

  or

- Manually reset two or more TelORB processors by pressing their respective
  reset button.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Monitor DHCP during TelORB processor reload
Start recording (4 hits is normal for each processor reload):
  snoop -o /tmp/output udp port 67  (/tmp/output=log file, 67=dhcp port)
                                    (Ctrl-C stops the recording)
View recording result:
  snoop -i /tmp/output -x 0 -v

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Zone reload or initial load fails
If the following printout is received, the pointed out TelORB processor ( 13 )
may be TelORB processor 16 (+3). This is not a rule, since the loadlink does
not have any information about this, but if the TelORB processors are in
consecutive order this may be the case.
For initial load, where TelORB processor 2 is held, add 2 (+2) to the pointed
out TelORB processor to get the real TelORB processor number (not a rule
either).

    ===< LoadLink Warning >===

    /ipims_dicos/ipims_dicos20/BS2/tbAD13/DICOS_SA/SoftwareSupport_SE/LoadingDriver_OB/LoadLinkDriver_OU/src/DswldMulticastHandler.cc(1142)

       DswldMulticastHandler::linkFailure( 13 )

            State: Wait For Rdy

    noOfConnectRetry 1793

    noOfConnectRetry 1794
     :

-  -  -  -  -  -  -

If the following printout is received during initial load, add 3 to the
destIndex (or index) value to get the pointed out TelORB processor, i.e. the
TelORB processor which does not load. In the case below, TelORB processor 8 is
pointed out (5+3).

    ===< LoadLink Warning >===
   /ipims_dicos/ipims_dicos20/BS2/tbAD14/DICOS_SA/SoftwareSupport_SE/LoadingDriver_OB/LoadLinkDriver_OU/src/DswldMulticastHandler.cc(423)
       Excluding destIndex: 5; Not connected or failed
     :
DEBUG INFO: LMD: Processor marked as failed, index = 5

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Index numbering of TelORB Processors
 (Updated: 2003-01-07)

The index numbering below is valid for TSP 4.0 (TelORB-R14-Linux).

In TelORB processor log printouts, the TelORB processor names are sometimes not
printed. Instead, index numbering is used. The index numbering of the TelORB
processors are initially decided by the order the TelORB processors appear in
the epct file.
Below, I have specified the index numbering for the EAB CW/OS lab test system
to29, consisting of 37 TelORB processors:

TelORB processor, as specified in epct file    Index numbering
-------------------------------------------    ---------------

PROCESSOR Proc_m0_s9  (Dicos) (Loader)            1.1
PROCESSOR Proc_m0_s11 (Dicos)                     1.2
PROCESSOR Proc_m0_s13 (Dicos)                     1.3
PROCESSOR Proc_m0_s15 (Dicos)                     1.4
PROCESSOR Proc_m0_s17 (Dicos)                     1.5
PROCESSOR Proc_m0_s19 (Dicos)                     1.6
PROCESSOR Proc_m0_s21 (Dicos)                     1.7
PROCESSOR Proc_m0_s23 (Dicos)                     1.8

PROCESSOR Proc_m1_s9  (Dicos) (Loader)            1.9
PROCESSOR Proc_m1_s11 (Dicos)                     1.10
PROCESSOR Proc_m1_s13 (Dicos)                     1.11
PROCESSOR Proc_m1_s15 (Dicos)                     1.12
PROCESSOR Proc_m1_s17 (Dicos)                     1.13
PROCESSOR Proc_m1_s19 (Dicos)                     1.14
PROCESSOR Proc_m1_s21 (Dicos)                     1.15
PROCESSOR Proc_m1_s23 (Dicos)                     1.16

PROCESSOR Proc_m3_s3  (Linux)                     1.17
PROCESSOR Proc_m3_s5  (Linux)                     1.18
PROCESSOR Proc_m3_s7  (Linux)                     1.19
PROCESSOR Proc_m3_s9  (Linux)                     1.20
PROCESSOR Proc_m3_s11 (Linux)                     1.21
PROCESSOR Proc_m3_s13 (Linux)                     1.22
PROCESSOR Proc_m3_s15 (Linux)                     1.23
PROCESSOR Proc_m3_s17 (Linux)                     1.24
PROCESSOR Proc_m3_s19 (Linux)                     1.25
PROCESSOR Proc_m3_s21 (Linux)                     1.26

PROCESSOR Proc_m4_s1  (Linux)                     1.27
PROCESSOR Proc_m4_s3  (Linux)                     1.28
PROCESSOR Proc_m4_s7  (Linux)                     1.29
PROCESSOR Proc_m4_s9  (Linux)                     1.30
PROCESSOR Proc_m4_s11 (Linux)                     1.31
PROCESSOR Proc_m4_s13 (Linux)                     1.32
PROCESSOR Proc_m4_s15 (Linux)                     1.33
PROCESSOR Proc_m4_s17 (Linux)                     1.34
PROCESSOR Proc_m4_s19 (Linux)                     1.35
PROCESSOR Proc_m4_s21 (Linux)                     1.36
PROCESSOR Proc_m4_s23 (Linux)                     1.37

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
When powering off ethernet switch A in the expansion cabinet, it may take two
zone reload attempts to get the zone up.
This is OK, since at the first load attempt, all TelORB processors may not be
in sync.
A software reset of all processors is automatically performed before the second
load attempt.
This results in that all processors are in sync and the zone reload should
therefore always be successful.
When powering off ethernet switch B in the expansion cabinet before a zone
reload, the zone usually comes up on the first attempt.
(R13)

Reload a TelORB processor
These guidelines describes 3 ways of reloading a TelORB processor.

Either  
- Use TelORB Browser - Processor List:
  Select TelORB processor to reload and click on "Configure Proc.".
- In the opened window for the selected TelORB processor, click on "Reload".
- Click on "Ok" to quit the window for the selected TelORB processor.

or
- Type "Ctrl-c" and "Enter" in the TelORB processor console for the TelORB
  processor to reload to stop the execution.
- Type "q" (and "q") in the stopped TelORB processor console to start the
  execution.

or
- Manually reset the TelORB processor to reload by pressing its reset button.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Some printouts in the TelORB processor console during reload of only TelORB processor 2
Reloading....
:
-----> All drivers started
:
-----> Starting kernel...
:
-----> Kernel started
-----> Established link through Ethernet A to [1.1.3]
-----> Established link through Ethernet A to [1.1.1]
-----> Established link through Ethernet A to [1.1.6]
:
-----> Base functionality started.
:
-----> Total functionality started.
:

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Loading attempts of TelORB processors
In AD9 the loading functionality tried 5 minutes on each net (10 minutes
totally). 
In AD11 this was changed so that the loading functionality switches network
every 20 seconds when trying to connect to a non-PLGL. However, the total
connect time (for the load link) was reduced to 5 minutes.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Loading attempts at failure to reload a TelORB processors
No second attempt to reload a TelORB processor is performed when the TelORB
processor has failed to reload. The TelORB processor will be automatically
disabled from the system after the first reload failure.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Monitor DHCP during TelORB processor reload
Start recording (4 hits is normal for each processor reload):
  snoop -o /tmp/output udp port 67  (/tmp/output=log file, 67=dhcp port)
                                    (Ctrl-C stops the recording)
View recording result:
  snoop -i /tmp/output -x 0 -v

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
It is possible to reload a TelORB processor even though no backup exists.

General
For complete instructions on how to REPLACE (i.e. remove and add) a TelORB
processor, use the official TelORB O&M documentation. These guidelines just
describes removal of a TelORB processor, since this was not previously described
in the official TelORB O&M documentation.

Note: In R13, if a removal/addition of a TelORB processor has been performed,
      do not attempt to reload the system from a backup that was created before
      the removal/addition. This will result in cyclic zone reloads.
      I.e. after removal/addition of a TelORB processor it is not possible to
      restore the TelORB system from an old backup
      (TR.1754 issued)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 1: Create an upgrade package and copy it to IO1
 (Updated: 2003-04-22)

The upgrade package will be used to remove one or several TelORB processors.
In the example below, 2 Dicos and 2 Linux processors will be removed.
At the EAB CW/OS lab, the procedure to create an upgrade package for removal of
TelORB processor(s) may look as follows:
- Go to the environment where the system was previously built, e.g.
  /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/ on tos1/tos2.
  Source the Envsettings file, if not already done.
- The upgrade package is created by running the epct command against two files:
  the configuration (.config) file which represents the state of the system
  before the upgrade, and the .epct file which you edit to reflect what the
  system should look like after the upgrade. The .config file was generated as
  a result of e.g. the last upgrade to the target system, and should already be
  available to you. If it has been accidently deleted or misplaced, a new one
  can be generated, see Create .config file.
- Create a new epct file where the TelORB processor(s) to be removed is
  excluded and the NAME parameter is changed to reflect the name of the upgrade
  package to be created, e.g. remove2d2l. If you are using several epct files to
  configure the system, also consider removing processor data in these epct
  files if they contain TelORB processor related information.
- Generate the upgrade package by running the epct command, as follows
  (-H = consider only HW changes):
    Example:
      epct -t i486 -F -v -H -u R14Linuxp5ToR14Linuxp7Step2.config r14_linux_mini_zone2_remove2d2l.epct demo2000_remove2d2l.epct viptest_remove2d2l.epct
        or (at the EAB CW/OS lab)
      epct -t i486 -F -v -H -u /to28/to28io1/telorb/axe/loadingGroup01_1/to28_maxi_system_r14lp7.config r14_linux_maxi_zone1_noExpCabinet_remove2d2l.epct demo2000_noExpCabinet_remove2d2l.epct viptest_noExpCabinet_remove2d2l.epct
        or
      epct -t i486 -F -v -H -u ../axe/to28_Mini_R15LSV508pre_DicosOnly.config r15_linux_mini_zone2_i686_remove_m0s23_m1s13.epct TSP_Ref_App_remove_m0s23_m1s13.epct vip.epct doi_stl_remove_m0s23_m1s13.epct
    Example of printout:
      os is i486-Redhat-6.0
      epct: reading R14Linuxp5ToR14Linuxp7Step2.config
      epct: processing input file r14_linux_mini_zone2_remove2d2l.epct
      epct: processing input file demo2000_remove2d2l.epct
      epct: processing input file viptest_remove2d2l.epct
      epct: Processor Proc_m0_s3 removed
      epct: Processor Proc_m0_s7 removed
      epct: Processor Proc_m1_s11 removed
      epct: Processor Proc_m1_s13 removed
      epct: building structure /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/remove2d2l
      epct: cleaning up /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/remove2d2l/
      epct: copying load files to /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/remove2d2l/codeArchive
      Use of uninitialized value at /home/dicostest/systest/tsp4.0/TelORB-R14-
        Linux-upto-patch7/TelORB-R14-Linux-Runtime3.4/system/TelORB/
        IDP_D23_R1AB01-DeploymentTools/included/LM_D84-DeploymentToolsLib/
        scripts/_epct line 2903.
      Use of uninitialized value at /home/dicostest/systest/tsp4.0/TelORB-R14-
        Linux-upto-patch7/TelORB-R14-Linux-Runtime3.4/system/TelORB/
        IDP_D23_R1AB01-DeploymentTools/included/LM_D84-DeploymentToolsLib/
        scripts/_epct line 2903.
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/remove2d2l/upgradeConfigurationData/upgradeControlData.01
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/remove2d2l/upgradeConfigurationData/upgradeControlData.02
      ************************************************************
       The generated upgrade package remove2d2l consists of :
            removed processor(s): Proc_m0_s7 Proc_m1_s11 Proc_m0_s3 Proc_m1_s13  

      **********************************************************
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/remove2d2l.config
    End of printout.

- Either copy the generated upgrade package to IO processor 1 of the system to be upgraded (on tos1/tos2):
    Example:
      cp -r /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/remove2d2l/ /to28/to28io1/telorb/axe/upgradePackages/

  or create a tar file of the upgrade package to be able to copy it to IO1: 
    Example:
      tar cf remove2d2l.tar /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/remove2d2l/
  Use e.g. ftp or sftp to copy the upgrade package to IO1.

Note that when the upgrade package was created, a new .config file was
generated, e.g. /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/remove2d2l.config.
This .config file may be used as input when creating an upgrade package to add
the same TelORB processor(s) as will be removed.


Step 2: Disable TelORB processor(s)
 (Updated: 2003-04-22)

Disable = move all DUs from the TelORB processor and kill it.

- Use the "Processors" card in the TelORB Manager:
  Select the TelORB processor(s) to remove and click "Disable".
  (To select several TelORB processors, use Shift + left mouse click to select
  a range of processors and use Ctrl + left mouse click to select individual
  processors.)
- Check that the notification(s) "Disable processor started" for the relevant
  TelORB processor(s) is received.
- Wait until notification(s) "Disable processor succeeded" is received or until
  "LOG_NOTICE: CM: Processor 1.x disabled successfully" is received in the
  processor log file for the active CM (for all disabled processors).
- Click "Rescan" and check that the selected TelORB processor(s) is marked in
  red color and also that the TelORB processor(s) is removed from the TelORB
  Processor Load Viewer window.



Step 3: Apply the upgrade package to remove TelORB processor(s)
 (Updated: 2003-04-22)

- Apply the upgrade package, which will result in a smooth upgrade.

The TelORB processor(s) will be removed from the TelORB system.



Step 4: Create software backup
 (Updated: 2003-04-22)

- Create a software backup.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
To check if the enable is finished use WWW as follows:
http://134.138.xx.101:5557/SWS/CM           (Adjust xx to valid network address)
                                            (Enter any TelORB processor)
Current CM state is: 4                      (Idle)

General
For complete instructions on how to REPLACE (i.e. remove and add) a TelORB
processor, use the official TelORB O&M documentation. These guidelines just
describes removal of a TelORB processor.

2001-01-17: This section was completely verified for AD9.05.3p17.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 1: Disable TelORB processor
Disable = move all DUs from the TelORB processor and kill it.

- Use TelORB Browser - Processor List:
  Select TelORB processor to remove and click on "Configure Proc.".
- In the opened window for the selected TelORB processor, click on "Get
  Processor State" which should show "In Service".
- In the opened window, click on "Disable".
- Check that notification "Disable Processor Started" for the relevant
  TelORB processor is received.
- Wait until notification "Disable Processor Succeeded" is received or until
  "LOG_NOTICE: CM: Processor 1.1 disabled successfully" is received in the
  processor log file for the active CM.
- Alarm "TelORB Processor unavailable" is received for the TelORB processor
  that is being removed.
- Check that the selected TelORB processor is removed from the TelORB
  Processor Load Viewer window.


Step 2: Remove TelORB processor
- In the opened window for the selected TelORB processor, click on "Get
  Processor State" which should show "Out of Service".
- In the opened window, click on "Remove".
  (The opened window for the selected TelORB processor is automatically
  removed.)
- Check that notification "Remove Processor Started" is received.
- Wait until notification "Remove Processor Succeeded" is received.
- Check that the TelORB processor that is removed is not visible in the
  TelORB Browser below the heading "Processors".

The TelORB processor is now removed from the TelORB system.


Step 3: Create software backup
- Create a software backup version.


Step 4: Edit epct file(s), if necessary
- If the removal of the TelORB processor is permanent, i.e. the TelORB system
  will keep this configuration, then remove the data about the removed TelORB
  processor from the epct file(s) in the build environment to reflect the TelORB
  system state.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
To check if the disable is finished use WWW as follows:
http://134.138.xx.101:5557/SWS/CM           (Adjust xx to valid network address)
                                            (Enter any TelORB processor)
Current CM state is: 4                      (Idle)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Old information for move all DUs (valid for AD4.xx)
- Use TelORB Browser - Processor List:
  Select TelORB processor to remove and click on "Configure Proc.".
- In the opened window for the selected TelORB processor, set "Max Move Time"
  to 1 and then click on "Move All DUs". "Max Move Time" refers to the state
  transfer time, i.e. the maximum time it takes for a process (instance) to
  transfer its state values (dynamic values, e.g. traffic data) from the TelORB
  processor to be removed to the created process on another TelORB processor.
  A better name for "Max Move Time" is "MaxStateTransferTime".
- Check that notification type 4 (Planned reconfiguration started) with
  OPERATION "moveAllDUs" is received.
- Wait until notification type 5 (Planned reconfiguration finished) is received.
- Check that the selected TelORB processor is emptied, in the Processor Load
  Viewer window.

General
 (Updated: 2003-05-19 for TSP 4)

The time it takes from the point when a TelORB processor is not reachable from
the CM (Configuration Manager) until it is excluded from the system, is
dependent on the type of TelORB processor:

- TelORB processor with TelORB OS which is loader (PLGL):         10 minutes
- TelORB processor with TelORB OS which is not loader (non-PLGL):  5 minutes
- TelORB processor with Linux OS (always loader):                 10 minutes

In the early TelORB days, the time for a PLGL was 30 minutes whereas the time
for a non-PLGL was 10 minutes.

The notifications (N) and alarm (A) to be received for a TelORB processor which
is not reachable for a longer period of time until it is excluded from the
system are as follows:
  N: Processor Reload Started
  N: Processor Reload Failed
  A: TelORB Processor unavailable
  N: Planned Reconfiguration Started
  N: Planned Reconfiguration Finished Successfully

General
For complete instructions on how to REPLACE (i.e. remove and add) a TelORB
processor, use the official TelORB O&M documentation. These guidelines just
describes addition of a TelORB processor, since this was not previously
described in the official TelORB O&M documentation.

Note: In R13, if a removal/addition of a TelORB processor has been performed,
      do not attempt to reload the system from a backup that was created before
      the removal/addition. This will result in cyclic zone reloads.
      I.e. after removal/addition of a TelORB processor it is not possible to
      restore the TelORB system from an old backup
      (TR.1754 issued)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 1: Create an upgrade package and copy it to IO1
 (Updated: 2003-04-22)

The upgrade package will be used to add one or several TelORB processors.
In the example below, 2 Dicos and 2 Linux processors will be added.
At the EAB CW/OS lab, the procedure to create an upgrade package for addition
of TelORB processor(s) may look as follows:
- Go to the environment where the system was previously built, e.g.
  /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/ on tos1/tos2.
  Source the Envsettings file, if not already done.
- The upgrade package is created by running the epct command against two files:
  the configuration (.config) file which represents the state of the system
  before the upgrade, and the .epct file which you edit to reflect what the
  system should look like after the upgrade. The .config file was generated as
  a result of e.g. the last upgrade to the target system, and should already be
  available to you. If it has been accidently deleted or misplaced, a new one
  can be generated, see Create .config file.
  If you previously removed the same TelORB processor(s) as you now want to add,
  you may use the .config file which was generated when the removal upgrade
  package was generated.
- Create a new epct file where the TelORB processor(s) to be added is
  included and the NAME parameter is changed to reflect the name of the upgrade
  package to be created, e.g. add2d2l. If you are using several epct files to
  configure the system, also consider adding processor data in these epct
  files if they contain TelORB processor related information.
  If you previously removed the same TelORB processor(s) as you now want to add,
  you may use the original epct file and just change the NAME parameter.

- Generate the upgrade package by running the epct command, as follows
  (-H = consider only HW changes):
    Example:
      epct -t i486 -F -v -H -u remove2d2l.config r14_linux_mini_zone2_add2d2l.epct demo2000.epct viptest.epct
        or (at the EAB CW/OS lab)
      epct -t i486 -F -v -H -u /to28/to28io1/telorb/axe/loadingGroup01_1/remove2d2l.config r14_linux_mini_zone2_add2d2l.epct demo2000.epct viptest.epct
    Example of printout: 
      os is i486-Redhat-6.0
      epct: reading remove2d2l.config
      epct: processing input file r14_linux_mini_zone2_add2d2l.epct
      epct: processing input file demo2000.epct
      epct: processing input file viptest.epct
      epct: Processor: Proc_m0_s3 added
      epct: Processor: Proc_m0_s7 added
      epct: Processor: Proc_m1_s11 added
      epct: Processor: Proc_m1_s13 added
      epct: building structure /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l
      epct: copying load files to /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/codeArchive
      Use of uninitialized value at /home/dicostest/systest/tsp4.0/TelORB-R14-
        Linux-upto-patch7/TelORB-R14-Linux-Runtime3.4/system/TelORB/
        IDP_D23_R1AB01-DeploymentTools/included/LM_D84-DeploymentToolsLib/
        scripts/_epct line 2903.
      Use of uninitialized value at /home/dicostest/systest/tsp4.0/TelORB-R14-
        Linux-upto-patch7/TelORB-R14-Linux-Runtime3.4/system/TelORB/
        IDP_D23_R1AB01-DeploymentTools/included/LM_D84-DeploymentToolsLib/
        scripts/_epct line 2903.
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/copy-data/networkAddresses.add2d2l
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/copy-data/Proc_m0_s3/processorConfiguration/kernelConfigurationDataLm
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/copy-data/Proc_m0_s7/processorConfiguration/kernelConfigurationDataLm
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/copy-data/Proc_m1_s11/processorConfiguration/kernelConfigurationDataLm
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/copy-data/Proc_m1_s13/processorConfiguration/kernelConfigurationDataLm
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/upgradeConfigurationData/upgradeControlData.01
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/upgradeConfigurationData/upgradeControlData.02
      ************************************************************
       The generated upgrade package add2d2l consists of :
            added processor(s): Proc_m0_s7 Proc_m1_s11 Proc_m0_s3 Proc_m1_s13  

      **********************************************************
      epct: generating /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/add2d2l.config
    End of printout.

- Either copy the generated upgrade package to IO processor 1 of the system to be upgraded (on tos1/tos2):
    Example:
      cp -r /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/ /to28/to28io1/telorb/axe/upgradePackages/

  or create a tar file of the upgrade package to be able to copy it to IO1: 
    Example:
      tar cf add2d2l.tar /home/dicostest/tosFiles/to28/TelORB-R14-Linux-Patch7/upgradePackages/add2d2l/
  Use e.g. ftp or sftp to copy the upgrade package to IO1.


Step 2: Apply the upgrade package to add TelORB processor(s)
 (Updated: 2003-04-22)

- Apply the upgrade package, which will result in a smooth upgrade.

The TelORB processor(s) will be added to the TelORB system.


Step 3: Enable TelORB processor(s)
 (Updated: 2003-04-22)

Enable = load the TelORB processor that has been added and supply it with DUs.
(Actually, DUs will be redistributed for all TelORB processors in the zone and
this may take a while.)

- Use the "Processors" card in the TelORB Manager:
  Select the TelORB processor(s) to add and click "Enable".
  (To select several TelORB processors, use Shift + left mouse click to select
  a range of processors and use Ctrl + left mouse click to select individual
  processors.)
- Check that the notification(s) "Enable processor started" for the relevant
  TelORB processor(s) is received.
- Wait until notification "Enable processor succeeded" is received or until
  "LOG_NOTICE: CM: Processor 1.x enabled successfully" is received in the
  processor log file for the active CM (for all enabled processors).
- Click "Rescan" and check that the selected TelORB processor(s) is no longer
  marked in red color and also that the TelORB processor(s) is visible in the
  TelORB Processor Load Viewer window.


Step 4: Create software backup
 (Updated: 2003-04-22)

- Create a software backup.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
To check if the disable is finished use WWW as follows:
http://134.138.xx.101:5557/SWS/CM           (Adjust xx to valid network address)
                                            (Enter any TelORB processor)
Current CM state is: 4                      (Idle)

General
For complete instructions on how to REPLACE (i.e. remove and add) a TelORB
processor, use the official TelORB O&M documentation. These guidelines just
describes removal of a TelORB processor.

In TelORB release R13 (and higher), the procedure to add a TelORB processor has
changed compared to AD12 and lower. In R13, the addition is performed by
creating an upgrade package which is not the case for AD12 and lower.

In R13, if a removal/addition of a TelORB processor has been performed, do not
attempt to reload the system from a backup that was created before the
removal/addition. This will result in cyclic zone reloads.
(TR.1754 issued)

2001-01-17: This section was completely verified for AD9.05.3p17
            (dhcpd.pxe.conf).

Note: The instructions below are valid for TelORB release AD12 and lower.
      I will update this section with the corresponding information for R13
      and higher when I get the time. Until then, use the official
      TelORB O&M documentation.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Step 1: Prerequisites
If a TelORB processor is to be added after a previous removal of the same TelORB
processor, where epct, networkaddresses and dhcp files as well as loadingGroup
directories have not been modified, this section (Prerequisites) should be
skipped, i.e. go directly to section Add TelORB processor.

The TelORB system to8 is used in the example below. In the example, two TelORB
processors (22 and 23) are added in one go (only valid for this section, i.e.
Prerequisites).

- Create a software backup version.

- Edit or create new epct files in the controlling environment as follows:
    - Add new processor data (processor name and MAC addresses).
      E.g. file processor.epct.
    - Add processor pool allocations for the new TelORB processors.
      E.g. files netred.epct, demo.epct, java.epct, pools.epct, doi.epct.

- Make a note of the SystemGenerationID (to be used later in the epct command)
  which is to be found on IO processor 1 (and 2) as follows:
    more /opt/telorb/axe/loadingGroup01_1/Processor1/processorConfiguration/kernelConfigurationDataLm

- Run epct, which will create the directory loadingGroup01_1 in the controlling
  environment and below this (among other files and directories) will create new
  Processor directories for the TelORB processor(s) to be added, as well as
  updating the file networkAddresses with information about the TelORB
  processor(s) to be added:
    epct -f loadingGroup01_1 -vF -P <SystemGenerationID> name.epct telorb.epct telorbDataDRTMS3.5M.epct processor28.epct demo28.epct java.epct ServicePlatform.epct pools28.epct netred28.epct
        (Adjust <SystemGenerationID> to valid id and use the newly created
         epct files. It does not matter which name.epct file that is used)

- Use tos1/tos2 to copy the new processor directoriy(ies) and the
  networkAddresses file to IO processor 1, e.g.:
    cd /to8/to8io1/telorb/axe/loadingGroup01_1/
    cp -r /home/dicostest/tosFiles/to8/JAMBALA2/loadingGroup01_1/Processor22 .
    cp -r /home/dicostest/tosFiles/to8/JAMBALA2/loadingGroup01_1/Processor23 .
    cp /home/dicostest/tosFiles/to8/JAMBALA2/loadingGroup01_1/networkAddresses .

- Use tos1/tos2 to copy the new processor directoriy(ies) and the
  networkAddresses file to IO processor 2, e.g.:
    cd /to8/to8io2/telorb/axe/loadingGroup01_2/
    cp -r /home/dicostest/tosFiles/to8/JAMBALA2/loadingGroup01_1/Processor22 .
    cp -r /home/dicostest/tosFiles/to8/JAMBALA2/loadingGroup01_1/Processor23 .
    cp /home/dicostest/tosFiles/to8/JAMBALA2/loadingGroup01_1/networkAddresses .

- Remove the directory loadingGroup01_1 from the controlling environment.

- Insert and connect the new TelORB processor board(s).

Follow these instructions if the dhcptab file set is used:
    - Modify DHCP files on IO processor 1, i.e. add the TelORB processors 22
      and 23 either manually or by entering the following commands.
        cd /var/dhcp/
        pntadm -A 134.138.81.122 -m net81telorb -f 'PERMANENT+MANUAL' -i 0100805000CE4D 134.138.81.0
        pntadm -A 134.138.82.122 -m net82telorb -f 'PERMANENT+MANUAL' -i 010080500096DD 134.138.82.0

        pntadm -A 134.138.81.123 -m net81telorb -f 'PERMANENT+MANUAL' -i 0100805000CEDD 134.138.81.0
        pntadm -A 134.138.82.123 -m net82telorb -f 'PERMANENT+MANUAL' -i 010080500096DC 134.138.82.0

        sort -u 134_138_81_0 134_138_82_0 | sort -k 3 > tmpfile
        cp tmpfile 134_138_81_0
        cp tmpfile 134_138_82_0

    - Repeat the same commands as given for IO processor 1 above, but for IO
      processor 2.

Follow these instructions if the dhcpd.pxe.conf file is used:
    - Modify the DHCPD file on IO processor 1, i.e. add the TelORB processors 22
      and 23 by entering the following commands.
        cd /opt/telorb/etc/
        Add data about the processor(s) to be added by editing the file
        dhcpd.pxe.conf, e.g. add the following:
		host p22_0 {
   			hardware ethernet 00:80:50:00:c9:01;
   			fixed-address     134.138.81.122;
		}

		host p22_1 {
   			hardware ethernet 00:80:50:00:c9:02;
   			fixed-address     134.138.82.122;
		}

		host p23_0 {
   			hardware ethernet 00:80:50:00:c9:03;
   			fixed-address     134.138.81.123;
		}

		host p23_1 {
   			hardware ethernet 00:80:50:00:c9:04;
   			fixed-address     134.138.82.123;
		}

    - Repeat the same editing for IO processor 2.


Step 2: Add TelORB processor
- Use TelORB Browser - Processor List: Click on "Add Processor".
- In the opened window "Add New Processor", fill in data for the TelORB
  processor to be added as follows:

  Name:                 Processor name, e.g. Processor6
  Subnet No.:           TelORB subnet (not TCP/IP subnet), e.g. 1
  Processor No.:        The index of the processor, e.g. 6
  Architecture:         E.g. i486

  Distribution Pools:  Comma separated list of string names of distribution
                       pools that this processor will be included in.
                       Note that no spaces are allowed between the distribution
                       pool names.
                       Fetch pool distribution from the epct file(s).
                       In the examples below, the HLR, AC and SCP pool
                       distributions are fetched from the Boston site 990924.

      Distribution pool examples for processors 1 and 2 (PLGLs):
        Dicos:     DicosCommonPool,DicosPlgLoaderPool,DicosDbReplicaPool,
                   DicosQnPool
        Netred:    DicosNetRedPool,DicosNetRedConnectPool
        Demo:      TrafficGeneratorPool  (on e.g. two TelORB processors where
                                          ApplicationPool is not located, e.g.
                                          on TelORB processors 1 and 2)
                   ApplicationPool       (on all TelORB processors, except where
                                          TrafficGeneratorPool is located)
        Java:      JavaDemoTGPool        (on e.g. two TelORB processors where
                                          JavaDemoAppPool is not located, e.g.
                                          on TelORB processors 3 and 4)
                   JavaDemoAppPool       (on all TelORB processors, except where
                                          JavaDemoTGPool is located)
        Omed:      OmedGeneratorPool     (on e.g. two TelORB processors where
                                          OmedWorkPool is not located, e.g.
                                          on TelORB processors 6 and 7)
                   OmedWorkPool          (on all TelORB processors, except where
                                          OmedGeneratorPool is located)
        HLR:       DbaPool
        AC:        -
        SCP:       -
        Populator: PopExePool
        DOI test:  CommonPool,DicosTestServerPool

      Distribution pool examples for processor 3 and upward (non PLGLs):
        Dicos:     DicosCommonPool
        Netred:    DicosNetRedPool
        Demo:      TrafficGeneratorPool  (on e.g. two TelORB processors where
                                          ApplicationPool is not located, e.g.
                                          on TelORB processors 1 and 2)
                   ApplicationPool       (on all TelORB processors, except where
                                          TrafficGeneratorPool is located)
        Java:      JavaDemoTGPool        (on e.g. two TelORB processors where
                                          JavaDemoAppPool is not located, e.g.
                                          on TelORB processors 3 and 4)
                   JavaDemoAppPool       (on all TelORB processors, except where
                                          JavaDemoTGPool is located)
        Omed:      OmedGeneratorPool     (on e.g. two TelORB processors where
                                          OmedWorkPool is not located, e.g.
                                          on TelORB processors 6 and 7)
                   OmedWorkPool          (on all TelORB processors, except where
                                          OmedGeneratorPool is located)
        HLR:       DistributorPool,HlrPool (Do not include DbaPool)
        AC:        AcPool
        SCP:       ScpPool
        Populator: PopPool
        DOI test:  CommonPool
                   LastProcPool          (on any 2 non-PLGL processors)

  Loading Group:        ProcessorLoadingGroup
  Is Loader:            To be ticked if the TelORB processor to be added is
                        a PLGL (Ticked=True, Not ticked=False)

- Click "Apply" to start the addition of the TelORB processor.
- Check that notification "Add Processor Started" is received.
- Wait until notification "Add Processor Succeeded" is received.
- Alarm "TelORB Processor unavailable" is received for the TelORB processor that
  is being added.
- Check that the TelORB processor that is being added is visible in the TelORB
  Browser below the heading "Processors". (The added TelORB processor will not
  yet be visible in the TelORB Processor Load Viewer window.)
- Quit the window "Add New Processor".


Step 3: Enable TelORB processor
Enable = load the TelORB processor that has been added and supply it with DUs.
(Actually, DUs will be redistributed for all TelORB processors in the zone and
this may take a while.)

- Use TelORB Browser - Processor List:
  Select the TelORB processor that is being added and click on "Configure
  Proc.".
- In the opened window for the selected TelORB processor, click on "Get
  Processor State" which should show "Out of Service".
- In the opened window, click on "Enable".
- Check that notification "Enable Processor Started" for the relevant TelORB
  processor is received. (The TelORB processor will be visible in the TelORB
  Processor Load Viewer window after it has been loaded, before supply with DUs
  starts.)
- Alarm "TelORB Processor unavailable" is cleared.
- Wait until notification "Enable Processor Succeeded" is received.
- In the opened window, click on "Get Processor State" which should show
  "In Service".
- Quit the window for the selected TelORB processor.

The TelORB processor is now added to the TelORB system.


Step 4: Create backup
- Create a software backup version.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
To check if the enable is finished use WWW as follows:
http://134.138.xx.101:5557/SWS/CM           (Adjust xx to valid network address)
                                            (Enter any TelORB processor)
Current CM state is: 4                      (Idle)

General
Prior to TSP 5, upgrade packages are used when adding or removing traffic
processors. This is not the case from TSP 5 and onwards.
The instructions below are valid for TSP 4.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions (Adjust toX to valid TelORB system name in the command lines below.) (Adjust rZZ to valid release directory.) Create an upgrade package (use tos1/tos2): - Go to where the system was previously built, e.g. cd /home/dicostest/tosFiles/toX/rZZ/ - Change the NAME value to reflect what is to be upgraded in the (name) epct file. - Source Envsettings, if it is valid (if not already done): source Envsettings - Make sure that the same epconfig settings as when previously building or upgrading the TelORB system are valid (if not, use command epconfig s): epconfig l -v - To include the LM(s) to be upgraded, either source a new Envsettings file or set epconfig settings towards the LM(s): epconfig s -r ... - Check which config file to use as input to the epct command below: ls -lrt /home/dicostest/tosFiles/toX/axe/ - Build the upgrade package, e.g.: epct -t i486 -v -F -d ../axe -u ../axe/system_name.config name.epct ... (New epct parameter "-V" introduced in R13p5 (use version checks on LMs)) - Check which upgrade method that will be used: more /home/dicostest/tosFiles/toX/axe/upgradePackages/... .../upgradeConfigurationData/upgradeControlData.01 - Check that the upgrade package contains the correct LM(s): more /home/dicostest/tosFiles/toX/axe/upgradePackages/... .../upgradeConfigurationData/upgradeControlData.02 - If the upgrading method "reboot" is to be used, do as follows: Edit the file "upgradeControlData.01" so that the upgrading method "DicosReboot:DicosNoDbu" will be used. Perform the upgrade: - Use the TelORB Manager/Browser to start the upgrade.

Introduction
There are three methods to upgrade TelORB software:

1. Smooth upgrade ------> Upgrading without bringing any TelORB processor
                          down. This method is used when upgrading applications.
                          If a smooth upgrade fails, the system is automatically
                          restored to the state it had before the upgrade, and
                          thus allowing a new upgrade attempt.
2. Redundancy upgrade --> Upgrading by bringing all TelORB processors down,
                          one at a time. This method is used when upgrading
                          TelORB kernel parts.
                          If a redundancy upgrade fails, there is nothing to
                          automatically restore the system from (except for a
                          zone reload from an older backup). In this case, a new
                          upgrade attempt may be performed manually, but this is
                          only possible if the upgrade package has not removed
                          any data from the database.
3. Reboot upgrade ------> Upgrading by bringing all TelORB processors down,
                          all at once. This method is used when upgrading
                          TelORB kernel parts, where it is possible to bring
                          down a zone for a short time (i.e., during the zone
                          reload, no traffic will be executed).

The smooth and redundancy upgrade methods will not disturb traffic and the
choice of upgrade method between these is decided by the TelORB system
(depending on each included "SW item's type").
The reboot upgrade method requires manual intervention, i.e. the upgrade method
in the file "upgradeControlData.01" has to be set to "DicosReboot".

If one or both of the IO processors is/are unavailable, it is not possible to
use any of the upgrade methods.

Due to improvements made in both TelORB R13 and TelORB R14, EAB CW/OS is able to
send out ready made upgrade packages, instead of sending out complex
instructions on how customers should build their site specific upgrade packages.

When upgrading two network redundant zones, the recommendation is to start with
the primary zone and then continue with the standby zone. No special precautions
need to be taken.
When redundancy upgrading two network redundant zones, the primary zone can be
upgraded by using the redundancy upgrade method and the standby zone can be
upgraded by using the reboot upgrade method. The disadvantage with this is that
the system will not have a standby side to fall back to during the reboot
upgrade of the standby zone. The advantage is time gain.

If an upgrade package contains an LM version which does already exist in the
system, the upgrade is performed, but codearchive on the IO processors is not
updated with the new LM (since it has the same version as already exists in
codearchive).

In addition to the three upgrade methods mentioned above, there is another 
method to upgrading software, called Backdoor upgrade. This method is to be used
if it is not possible to use the ordinary upgrade functionality, e.g. in case of
cyclic zone reloads.
                         
== == == == == == == == == == == == == == == == == == == == == == == == == ==

Select alternative
Select one of the following alternatives (which do not have anything to do with
the three upgrade methods described above):

1. If the upgrade package that is going to be used when performing the upgrade
   already exists, put it on IO processor 1 below directory
   /opt/telorb/axe/upgradePackages
   and continue by following the instructions in
   Perform the upgrade.

2. If an upgrade package does not already exist, continue at
   Create a new epct file to be used when building the upgrade package.

3. If an upgrade package for testing purposes is to be created, go to
   Create test LMs to be used when testing software upgrade
   to get information about how test LMs (to be included in the upgrade package)
   are being built and then continue below.

4. If it is not possible to use the ordinary upgrade functionality, e.g. in case
   of cyclic zone reloads, go to Backdoor upgrade.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Create a new epct file to be used when building the upgrade package
The NAME variable value that is specified in the epct file, that is used as
input when building the upgrade package, will later be the name of the upgrade
package. Therefore the NAME variable value should be set to reflect what the
upgrade package will contain.

Either, for splitted epct files:
  - In the build environment, open the file "name.epct" (or equivalent) in an
    editor and edit the value of the variable "NAME" to reflect what the upgrade
    package will contain, e.g.:
    - A patch release going from e.g. AD12.4 patch 2 to AD12.4 patch 3 may be
      named "AD124p2toAD124p3".
    - A test LM for e.g. DicosKernel may be named "AD124_DicosKernel_R1G06T" to
      indicate which LM that is to be upgraded, along with its version and which
      AD (or TB) it is valid for.
  
  - Save the file with a name that indicates what the upgrade package will
    contain, e.g. "AD124p2toAD124p3.epct" or "name_DicosKernel_R1G06T.epct".
    The file will later be used as input to the epct command. Do not overwrite
    the name.epct file!

or, for combined epct file:
  - In the build environment, perform the same procedure as for when using
    splitted epct files, but use the combined epct file that covers all
    settings.
  - Save the file with a different name, i.e. do not overwrite the original
    file!

Note: If the upgrade package is to be used to upgrade other TelORB systems, do
      not edit the value of the variable "NAME" to include the name of one of
      the TelORB systems, since all TelORB systems, using the upgrade package,
      will then be named the same.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Build upgrade package - preparations (part 1)
From now on, tos1 or tos2 has to be used (preferably use the shell that was used
when the system was previously built or upgraded).

In a tos1/tos2 shell, go to where the system was previously built and enter the
following:
  cd /home/dicostest/tosFiles/toX/ad12.4/    (Adjust toX to valid TelORB system
                                              and ad12.4 to valid release)
  source Envsettings

Make sure that the same epconfig settings as when previously building or
upgrading the TelORB system are valid:
  epconfig l -v

If not, use command `epconfig s' to restore the epconfig settings to the
settings that are valid for the TelORB system to be upgraded (see the
`epconfig s' part in section Build TelORB system loading groups for further
information).

-  -  -

Add the upgrade changes to epconfig depending on what to upgrade:

    For upgrading to a new AD release, e.g. from AD12.3 to AD12.4 (Redundancy or
    smooth upgrade depending on the AD contents):

    - Change the file Envsettings to fetch from the new AD release.
    - Source the file Envsettings:
        source Envsettings


    For upgrading of a patch package, e.g. patch3 in AD12.4 (Redundancy or
    smooth upgrade depending on the patch package contents):

    epconfig s -r /ipims_dicos/ipims_dicos10/dists/AD12.4-patch/official/patch3/
      (Adjust AD12.4 to valid release and patch3 to valid patch package)

    epconfig l -v patch3            (Check all epconfig settings from patch8)

    ( epconfig l -v                 (Check all epconfig settings) )


    For upgrading of DicosKernel LM (Redundancy upgrade of a C++ LM for testing
    purposes) (The LM has to be prepared in section
    Create test LMs to be used when testing software upgrade):

    Either if the test LM was previously fetched from an AD release (adjust
    ad12.4 to valid release):
      epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/LM_AXG561-DicosKernel

    or if the test LM was previously fetched from a patch release (adjust
    ad12.4 to valid release):
      epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/DicosKernel_LM

    epconfig l -v testLMs           (Check all epconfig settings from testLMs)

    ( epconfig l -v                 (Check all epconfig settings) )


    For upgrading of JavaMain LM (Redundancy upgrade of a Java LM for testing
    purposes) (The LM has to be prepared in section
    Create test LMs to be used when testing software upgrade):

    Either if the test LM was previously fetched from an AD release (adjust
    ad12.4 to valid release):
      epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/LM_MD48-JavaMain/

    or if the test LM was previously fetched from a patch release (adjust
    ad12.4 to valid release):
      epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/JavaMain_LM/

    epconfig l -v testLMs           (Check all epconfig settings from testLMs)

    ( epconfig l -v                 (Check all epconfig settings) )


    For upgrading of DemoApp and DemoTG LMs (Smooth upgrade of C++ LMs for testing
    purposes) (The LMs have to be prepared in section
    Create test LMs to be used when testing software upgrade):

    epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/LM_DEA9980-DeApp_App/
      (Adjust ad12.4 to valid release)
    epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/LM_DEA9981-DeApp_TG_LM/
      (Adjust ad12.4 to valid release)

    epconfig l -v testLMs           (Check all epconfig settings from testLMs)

    ( epconfig l -v                 (Check all epconfig settings) )


    For upgrading of JavaDemo LM (Smooth upgrade of a Java LM for testing
    purposes) (The LM has to be prepared in section
    Create test LMs to be used when testing software upgrade):

      Either if the test LM was previously fetched from an AD release (adjust
      ad12.4 to valid release):
        epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/LM_D2-JavaDemo/

      or if the test LM was previously fetched from a patch release (adjust
      ad12.4 to valid release):
        epconfig s /home/dicostest/systest/ad/ad12.4/testLMs/JavaDemo_LM/

    epconfig l -v testLMs           (Check all epconfig settings from testLMs)

    ( epconfig l -v                 (Check all epconfig settings) )


    For upgrading of Omed which has pools that are not yet defined in the
    TelORB system (Smooth upgrade of Omed for testing purposes):

    epconfig s -r /ipims_dicos/ipims_dicos20/BS2/tbAD9.05/TEST_IDPG/Omed_IDP/

    epconfig l -v testLMs           (Check all epconfig settings from testLMs)

    ( epconfig l -v                 (Check all epconfig settings) )

    (Include the epct file for omed, which was not included before:
    epct -t i486 -c -d ../axe -u ../axe/To8_28_processors_ZONE1.config -vF name_upg_ad9053_omed_schema.epct telorb.epct telorbDataDRTMS3.5M.epct processor28.epct servicePlatform.epct pools28.epct netred28.epct demo28.epct omed28.epct)

    Modify the following file on IO1:
       /opt/telorb/axe/upgradePackages/28_processors_AD9053_omed_schema/upgradeConfigurationData
       Add the following lines for each TelORB processor which should be
       included in OmedWorkPool:

         SET DcpsimEmMo <252033 = "ProcessorX">
           distributionPools += 
           <
             <152004 = "SoftwareManagement", 152004 = "SoftwareConfiguration", 
                152004 = "OmedWorkPool">
           >;

       Add the following lines for each TelORB processor which should be
       included in OmedGeneratorPool:

         SET DcpsimEmMo <252033 = "ProcessorX">
           distributionPools += 
           <
             <152004 = "SoftwareManagement", 152004 = "SoftwareConfiguration", 
                152004 = "OmedGeneratorPool">
           >;

    For further info, see TR.895.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Build upgrade package - preparations (part 2)
Check which config file to use in the epct command further down (i.e. the config
file that was created when last building the system for initial load or when it
was last upgraded):

  ls -lrt /home/dicostest/tosFiles/toX/axe/  (Adjust toX to valid TelORB system)

    or

  Check that the config file, to be used when executing the epct command below,
  corresponds to the name of the TelORB system:
  - Use TelORB Browser - Processor List: Click on "Configuration Mgr.".
  - In the opened window "Configuration Tool", click on "Name".
  - Quit the window "Configuration Tool".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Build upgrade package - execution
When building the upgrade package, the same epct file(s) as used when previously
built or upgraded the system must be used, except for the name epct file which
is substituted for the name epct file that was created above.
However, if a new LM or IDP, that does not exist in the TelORB system to
be upgraded, is to be included in the upgrade package, the new LM or IDP must be
included in the corresponding epct file.
The config file (e.g. system_name.config) contains information about the TelORB
processors' software configurations.

Still use tos1/tos2.

  cd /home/dicostest/tosFiles/toX/ad12.4/    (Adjust toX to valid TelORB system
                                              and ad12.4 to valid release)

  Either for splitted epct files (this is just an example; use the config and
  epct files that are valid for the TelORB system that you are working on):

    epct -t i486 -v -F -d ../axe -u ../axe/system_name.config name_DicosKernel_R1G06T.epct telorb.epct telorbData.epct processor.epct servicePlatform.epct pools.epct netred.epct demo.epct
      (Adjust system_name.config to valid name config file)
      (Adjust name_DicosKernel_R1G06T.epct to valid name epct file)
      (../axe = /home/dicostest/tosFiles/toX/axe)

  or for combined epct file (this is just an example; use the config and
  epct files that are valid for the TelORB system that you are working on):

    epct -v -t i486 -d ~/toX/axe -f loadingGroup01_1 -u ~/toX/axe/system_name.config -vF combined.epct
      (~/toX/axe = /home/dicostest/tosFiles/toX/axe)

    (New epct parameter "-V" introduced in R13p5 (use version checks on LMs))


  Hints:
  -d = where to output
  -u = where to fetch input

  Old info:
  epct -t i486 -vFc -d axe -u axe/system_name.config name_red.epct processor.epct telorbData.epct demo.epct omed.epct java.epct  (uabhenn)

  epct -v -t i486 -d ~/toX/axe -u ~/toX/axe/system_name.config -vF name_red.epct processor.epct telorbData.epct demo.epct omed.epct java.epct
    (where ToX_Initial.config is the config file to start from and
    name_red.epct is the file that was previously manually created in this
    section)
     (~/toX/axe = /home/dicostest/tosFiles/toX/axe)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check which upgrade method that will be used
Either the upgrade method DicosRedundancyReboot or DicosSmooth will be used.
Take the path from the last part of the epct result printout, e.g.:
more /home/dicostest/tosFiles/toX/axe/upgradePackages/AD124_DicosKernel_R1G06T/upgradeConfigurationData/upgradeControlData.01
  (Adjust toX to valid TelORB system)
  (Adjust AD124_DicosKernel_R1G06T to name of upgrade package)

This file will e.g. show:
  "UA:AD124p2_LM_AXG561DicosKernelR1G06T:DicosRedundancyReboot:DicosNoDbu"
which means that the redundancy upgrade method will be used.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check that the upgrade package is not empty and also which LM(s) that are included
The upgrade package will physically only contain the changed LM(s)
(e.g. DicosKernel.LM_AXG561.Code.R1G06T.i486).
Take the path from the last part of the epct result printout, e.g.:
more /home/dicostest/tosFiles/toX/axe/upgradePackages/AD124_DicosKernel_R1G06T/upgradeConfigurationData/upgradeControlData.02
  (Adjust toX to valid TelORB system)
  (Adjust AD124_DicosKernel_R1G06T to name of upgrade package)

This file will e.g. show:

  "LMA:LM/AXG561:R1F06T:codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R1F06T.i486,i486,1560064,1217530580,-424310901
   DUTA:DicosKernel_DUT.LM_AXG561:R1F06T"
  
which means that only the LM DicosKernel is included in the upgrade package.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check that output files have been created
Verify that the new upgrade package is put on IO processor 1 below directory
ls -lrt /opt/telorb/axe/upgradePackages/         (e.g. AD124_DicosKernel_R1G06T)

Verify that the new config file can be found below directory
ls -lrt /home/dicostest/tosFiles/toX/axe  (Adjust toX to valid TelORB system)
                                          (e.g. AD124_DicosKernel_R1G06T.config)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

If the upgrading method "reboot" is to be used, modify the file "upgradeControlData.01"
This part is only to be followed when the reboot upgrade method is to be used,
see Upgrade software / Introduction above for an explanation of this method.
- Edit the file (adjust toX and AD124_DicosKernel_R1G06T in the path)
  /home/dicostest/tosFiles/toX/axe/upgradePackages/AD124_DicosKernel_R1G06T/upgradeConfigurationData/upgradeControlData.01
  so that the upgrading method "reboot" will be used, i.e. set method equal to
  DicosReboot. After the modification the method line should look something like:
  "UA:toX_tbAD113_newtestkernel:DicosReboot:DicosNoDbu"
  (E.g. for a redundancy upgrade the string "Redundancy" is just removed from
  the line "UA:toX_tbAD113_newtestkernel:DicosRedundancyReboot:DicosNoDbu".)
- Save the file.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Perform the upgrade
- Use TelORB Browser - Processor List: Click on "Software Upgrade".
- In the opened window "Software Upgrade", click on "Scan".
  (Scans from IO1, /opt/telorb/axe/upgradePackages/)
- Check that notification type 22 (System Upgrade Scan Success) is
  received.
- In the window "Software Upgrade", click on the appropriate upgrade package.
- In the window "Software Upgrade", click on "Start".
- Wait until the following notification types are received:
    Generally:  7 (System upgrade started)
               16 (Backup started)               (not valid for smooth upgrade)
               17 (Backup finished successfully) (not valid for smooth upgrade)

    For each affected TelORB processor (only valid for redundancy upgrade):
                4 (Planned reconfiguration started, moveAllDUs)
                5 (Planned reconfiguration finished)
                1 (Processor reload started)
                2 (Processor reload finished successfully)
                4 (Planned reconfiguration started, supplyWithDUs)
                5 (Planned reconfiguration finished)
                The order of appearance of the TelORB processors in the
                TelORB Browser - Processor List shows in which order the TelORB
                processors are upgraded. However, the upgrade always ends with 
                upgrading TelORB processor 2.               
                Follow the upgrade in the TelORB processor Load Viewer window.

    Generally:  8 (System upgrade finished successfully) (not valid for reboot
                                                          upgrade)
                      (991102 notification type 9 (System Upgrade Failed)
                       was received after a reboot upgrade. This will be fixed)

- Create a software backup version.

If desired, remove the upgrade package on IO processor 1 as follows:
- In the window "Software Upgrade", click on the appropriate upgrade package.
- In the window "Software Upgrade", click on "Remove".
- Check that notification type 24 (Software upgrade remove successful) is
  received.

Leave the upgrade config file for future upgradings (i.e. as a start off file
when doing epct for the next upgrade package):
  ls -l /home/dicostest/tosFiles/toX/axe    (Adjust toX to valid TelORB system)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

If a redundancy upgrade fails
This section is not considered ready yet, so do not follow the instructions
below.

If a redundancy upgrade fails, the TelORB processors where the upgrade was
successful will contain the upgraded software whereas the TelORB processors
which have not yet been upgraded will contain the "old" software. For the TelORB
processor where the upgrade failed, it is uncertain whether it contains the
old or the new software or perhaps a mixture, depending on in which upgrading
phase the upgrade failed.
Check alarms, notifications, dumps and TelORB processor logs and try to find out
why the upgrade failed.
If there seems to be a problem with the new software to be upgraded, the system
should be brought back to the "old" software as follows:
- If no traffic disturbances are allowed and if no traffic data should be lost,
  build a downgrade package to be able to restore the "old" software.
  For AD12 and lower, it is possible to use the upgrade functionality to
  upgrade (downgrade) to e.g. an LM with the same version (e.g. R1H03) as
  already exists in the system. This is not possible in R13 and higher where the
  upgrade (downgrade) package has to be rebuilt with a special flag in the epct
  command to allow upgrading (downgrading) of LMs with the same versions.
  Apply the downgrade package.

- If major traffic disturbances are allowed, activate an older valid backup
  version and reload the system from that backup.
- If no traffic disturbances are allowed, activate an older valid backup
  version.
  Thereafter disable the TelORB processor where the upgrade failed, reload it,
  and enable it.
  Then disable, reload and enable the TelORB processors for which the upgrade
  was successful, one at a time.
Either of the methods above will bring you back to an earlier set of data.

If you are absolutely sure that the software that is being upgraded is free from
faults, it is possible to continue with the upgrade as follows:
- For AD12 and lower: Since the software to be upgraded exists on the active
  backup, disable the TelORB processor that failed, reload it, and enable it.
  Thereafter disable, reload and enable the TelORB processors which have not yet
  been upgraded, one at a time. (Build downgrade package?)
- For R13 and higher: Start the upgrade using the same upgrade package as
  before. This will upgrade the already upgraded TelORB processors once more and
  then continue with the rest of the TelORB processors. (Build downgrade
  package with new epct flag?)


Build upgradepackage with De2Sub and De2SubLinux
================================================
epconfig s /home/dicostest/systest/tsp4.0/testLMs/De2Sub_LM
epconfig s /home/dicostest/systest/tsp4.0/testLMs/De2SubLinux_LM

epct -t i486 -v -F -d ../axe -u ../axe/TO28_TelORB_Linux_3_3.config r14_linux_mini_zone2.epct demo2000.epct name_De2SubTestversion.epct
=====
epconfig d LM/PRO401
epconfig d LM/PRO411

epct -t i486 -v -F -d ../axe -u ../axe/De2SubTestVersion.config r14_linux_mini_zone2.epct demo2000.epct


Build upgradepackage with De2SubJavaLinux_LM
============================================
epconfig s /home/dicoshack/Hack/uabadas/testLMs/De2SubJavaLinux_LM

epct -t i486 -v -V -F -d ../axe -u ../axe/TO28_TelORB_Linux_3_3.config r14_linux_mini_zone2.epct demo2000.epct Demo.epct name_De2SubJavaLinux.epct
=====
epconfig d LM/PRO412

epct -t i486 -v -V -F -d ../axe -u ../axe/De2SubJavaLinux.config r14_linux_mini_zone2.epct demo2000.epct Demo.epct


Build upgradepackage with testversion of HelloWorld
===================================================
epconfig s /home/dicoshack/Hack/uabadas/testLMs/DicosJavaHelloErr/DicosJavaHello/Hello_IDP/Hello_LM

epct -t i486 -v -V -F -d ../axe -u ../axe/TO28_TelORB_Linux_3_3.config r14_linux_mini_zone2.epct DicosJavaHello.epct name_HelloOrg.epct
=====
epconfig s /home/dicoshack/Hack/uabadas/testLMs/DicosJavaHello/Hello_IDP/Hello_LM

epct -t i486 -v -V -F -d ../axe -u ../axe/HelloOrg.config r14_linux_mini_zone2.epct DicosJavaHello.epct

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Shortcut upgrade instructions
Old Stuff from to25
===================
Build upgradepackage with De2SubJavaLinux and De2SubJava
========================================================
epconfig s /home/dicoshack/Hack/uabadas/testLMs/DicosJavaHelloErr/DicosJavaHello/Hello_IDP/Hello_LM
epco

epct -t i486 -v -F -d ../axe -u ../axe/TO28_TelORB_Linux_3_3.config r14_linux_micro_zone1.epct demo2000.epct name_De2SubJavaTestVersion.epct

=====
epconfig d LM/PRO402
epconfig d LM/PRO412

epct -t i486 -v -F -d ../axe -u ../axe/De2SubJavaTestVersion.config r14_linux_micro_zone1.epct demo2000.epct


Remove one Dicos processor
====================================
epct -t i486 -v -F -H -d ../axe -u ../axe/to25_tbTelorbLinux3_2_micro.config Remove_One_Dicos.epct

epct -t i486 -v -F -H -d ../axe -u ../axe/RemoveOneDicos.config r14_linux_micro_zone1.epct demo2000.epct name_InsertOneDicos.epct


Build upgradepackage with De2Sub and De2SubLinux
================================================
epconfig s /home/dicostest/systest/tsp4.0/testLMs/De2Sub_LM
epconfig s /home/dicostest/systest/tsp4.0/testLMs/De2SubLinux_LM

epct -t i486 -v -F -d ../axe -u ../axe/to25_tbTelorbLinux3_2_micro.config r14_linux_micro_zone1.epct demo2000.epct name_De2SubTestversion.epct
=====
epconfig d LM/PRO401
epconfig d LM/PRO411

epct -t i486 -v -F -d ../axe -u ../axe/De2SubTestVersion.config r14_linux_micro_zone1.epct demo2000.epct


Build upgradepackage to install DBN
====================================
epct -t i486 -v -F -d ../axe -u ../axe/no_DBN.config r14_linux_micro_zone1.epct demo2000.epct


Remove and insert one Dicos and one Linux processor
===================================================
epct -t i486 -v -F -H -d ../axe -u ../axe/to25_tbTelorbLinux3_2_micro.config Remove_Two_Processors.epct

===Back to normal system
epct -t i486 -v -F -H -d ../axe -u ../axe/RemoveTwoProcessors.config r14_linux_micro_zone1.epct demo2000.epct

===Back to a normal system from a overload system
epct -t i486 -v -F -H -d ../axe -u ../axe/RemoveTwoProcessors.config InstallTwoTPsfromOverload.epct


Remove and insert one Linux processor
=====================================
epct -t i486 -v -F -H -d ../axe -u ../axe/to25_tbTelorbLinux3_2_micro.config Remove_One_Linux.epct

epct -t i486 -v -F -H -d ../axe -u ../axe/RemoveOneLinux.config r14_linux_micro_zone1.epct demo2000.epct



Build upgradepackage with DicosKernel
=====================================
epconfig s /home/dicostest/systest/tsp4.0/testLMs/DicosKernel_LM

epct -t i486 -v -F -d ../axe -u ../axe/to25_tbTelorbLinux3_2_micro.config r14_linux_micro_zone1.epct demo2000.epct name_DicosKernelTestVersion.epct

=====
epconfig d LM/AXG561

epct -t i486 -v -F -d ../axe -u ../axe/DicosKernelTestVersion.config r14_linux_micro_zone1.epct demo2000.epct

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
If you have prepared IO processor 1 with the upgrade package and it is
not found when scanning the available packages, check that directory
/opt/telorb/axe/upgradePackages does not exist on IO processor 2. If it does,
remove directory upgradePackages recursively and rebuild the system.

-  -  -

If a TelORB processor never reloads after reboot of another TelORB processor
during a redundancy upgrade, i.e. during a redundancy upgrade, e.g. processor 1
is manually rebooted while e.g. processor 3 is loading non-base-functionality.
processor 1 reloads OK, but processor 3 enters the while loop and never
automatically reloads.
To get out of this unpleasant state (i.e. processor 3 down, processor 1
containing "new" software and the rest of the processors containing "old"
software), manually remove processor 3, then remove the upgrade package via the
GUI, then scan the upgrade packages via the GUI, and thereafter order a new
software upgrade via the GUI from the same upgrade package as before.
See also TR 743.

-  -  -

If a (redundancy) upgrade fails, check the TelORB processor log files to find
the reason for the failure. If the reason is body checksum error for an LM, the
LM which is pointed out probably already exists with the same version in the
/opt/telorb/axe/loadingGroup01_n/codeArchive/ directory, but with a different
content. If this is the case, the LM can be removed from
/opt/telorb/axe/loadingGroup01_1/codeArchive/ on IO1 and IO2 if this is not the
"active" LM
(e.g. rm /opt/telorb/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R1I11.i486)
If several LMs are affected in this way, all these LMs must be removed from the
directory
/opt/telorb/axe/loadingGroup01_1/codeArchive/ on IO1 and IO2
to get a successful upgrade. To get this information, check which LMs that are
affected by the upgrade by checking the contents of the upgrade package at
/opt/telorb/axe/upgradePackages/<name_of_upgradepackage>/codeArchive/ on IO1
(e.g. /opt/telorb/axe/upgradePackages/upgradeDicosKernel/codeArchive/Dicos.IDP_MD14/DicosKernel.LM_AXG561.Code.R1I11.i486).
Remember not to remove any "active" LMs, i.e. maybe an older backup version is
to be returned to before starting to remove LMs. 

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Example of a Release Note/Delivery Note
This is an instruction how to upgrade from TelORB-AD4.11
to TelORB-AD4.12 using the reboot method. We will also 
change "PROMs".

This is basically a zone reload which means that the system 
will be down for a while but there is no need to re-populate 
the database afterwards.

Pre-condition: 
==============

You must have a TelORB-AD4.11-system running and have access to 
valid configuration files (epct and .config files) for the 4.11 
system. Your EP_WORKSPACE-variable must also be set to "match"
the configuration in the running system.

You must also have access to the TelORB-AD4.12 package:

** TelORB-AD4.12-inc


Reboot upgrade, step by step:
=============================

1. Make sure the EP_WORKSPACE-variable is set to "match"
   the configuration in the running system.
   Then configure the LMs to upgraded. 
  
 % epconfig s -r <your path>/TelORB-AD4.12-inc/system/runtime/
   
   Make sure the LMs are configured properly.....

2. Change the name of your TelORB system, this is done
   by changing the variable "NAME" in the epct file.
   Copy your epct file and give it a new name, for example:

 % cp 4_11.epct 4_12.epct

   Change the system-name in the 4_12.epct file:

 % textedit 4_12.epct &

   Change the name to, for example "4_12".

3. Now it's time to create the actual upgrade package, this 
   is done by using the epct-command.
   For example:

 % epct -v -t i486 -d axe -u axe/4_11.config 4_12.epct

   Make sure epct has created the upgrade package.
   Check the filesystem, for example:

 % ls -l axe/upgradePackages/4_12

4. In the generated upgrade package it's stated 
   that the upgrade method is redundancy reboot, epct
   has decided this and it might look something like 
   this:

 % more axe/upgradePackages/4_12/upgradeConfigurationData/upgradeControlData.01

CREATE DicosUpgrade <152004 = "SoftwareManagement", 152004 = "UpgradeServices", 152004 = "4_12">
  method = DicosRedundancyReboot,
  databaseUpgrade = DicosNoDbu;

   Now, we don't want the redundancy reboot method - we want 
   the reboot method. Therefore, change the method to the 
   reboot method, for example:

 % textedit axe/upgradePackages/4_12/upgradeConfigurationData/upgradeControlData.01 &

   The file content should after your change look  
   something like:

 % more axe/upgradePackages/4_12/upgradeConfigurationData/upgradeControlData.01

CREATE DicosUpgrade <152004 = "SoftwareManagement", 152004 = "UpgradeServices", 152004 = "4_12">
  method = DicosReboot,
  databaseUpgrade = DicosNoDbu;

5. Now it's time to start the upgrade.
   In the GUI, scan the upgrade packages. Make
   sure your new package is visible.
   Start the upgrade!
   
6. The upgrade functionality will reload the zone! 
   When the zone is down, change to the 4.12-PROMs in all 
   processors (changing "PROMs" is not further described here). 
   
   When all the "PROMs" have been changed, bring the zone up again
   by rebooting all the processors simultaneously.
 
   NOTE: No notfication will be sent saying that the upgrade
   is finished. 

7. The End.

General
The following example on how to create test LMs is written for AD12.4 which
corresponds to TB12.4, but the examples are also valid for other releases.

- Open a shell. Do not use tos1 or tos2, because the compilation won't work on
  these.

- Select or create a directory where your test LM(s) will be stored as follows
  (this is just a recommendation for reuse reasons; you can put the test LM(s)
  wherever you like):
    cd /home/dicostest/systest/ad/
    mkdir ad12.4       (Adjust ad12.4 to valid release)
    cd ad12.4          (Adjust ad12.4 to valid release)
    mkdir testLMs
    cd testLMs

- Set up environment:

    mkdir epws         (Create directory "epws")

    Execute the following lines that are taken from the file Envsettings.
    Be sure to use the testbed (e.g. tbAD12.4) that corresponds to the AD
    release (e.g. AD12.4) of the TelORB system to be upgraded or use a testbed
    (e.g. tbAD12.4p9) that corresponds to the AD and patch release (e.g.
    AD12.4 patch9) of the TelORB system to be upgraded:
      source /ipims_dicos/BS2/tbAD12.4/IP_CONF_INFO/EnvSettings (Adjust tbAD12.4
                                                               to valid release)
        (or
         source /ipims_dicos/BS2/tbAD12.4p9/IP_CONF_INFO/EnvSettings (Adjust
                                                   tbAD12.4p9 to valid release))

      setenv EP_WORKSPACE `pwd`/epws
      setenv DICOS_FILESYSTEM_ROOT `pwd`/axe
  
- Select one or several of the following test LM(s) to be included in the
  upgrade package (or select another LM which is not included below and then
  follow the nextcoming section):

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Create test LM for "DicosKernel" to test redundancy upgrade of a C++ LM
- Go to the directory where the test LM will be put, e.g.
  cd /home/dicostest/systest/ad/ad12.4/testLMs/     (Adjust AD to valid release)

- Copy the LM from the AD release or from the patch release (or TB) that the
  TelORB system to be upgraded is loaded with, as exemplified below:
    If the test LM is to be fetched from an AD release:
      cp -r /ipims_dicos/ipims_dicos10/dists/TelORB-AD12.4/system/runtime/IDP_MD14-Dicos/LM_AXG561-DicosKernel/ .
        (Adjust AD to valid release)

    or if the test LM is to be fetched from a patch release:
      cp -r /ipims_dicos/ipims_dicos10/dists/AD12.4-patch/official/patch2/DicosKernel_LM/ .
        (Adjust AD to valid release and patch to valid patch package)

    or if the test LM is to be fetched from a testbed (not further described in
    this section):
      cp -r 
/ipims_dicos/ipims_dicos20/BS2/tbAD12.4/DICOS_IDPG/Dicos_IDP/DicosKernel_LM/ .
        (Adjust tbAD to valid release)

    or if the test LM is to be fetched from a patch in a testbed (not further
    described in this section):
      cp -r /ipims_dicos/ipims_dicos20/BS2/tbAD12.4p2/LMs/DicosKernel_LM/ .
        (Adjust tbAD to valid release)

---

- Go to where the binary file(s) of the test LM is located:
    If the test LM was fetched from an AD release:
      cd LM_AXG561-DicosKernel/bin/

    or if the test LM was fetched from a patch release:
      cd DicosKernel_LM/bin/

- Delete all the binary code files of the test LM (they will later be
  recreated with the upgrade version after the epbuild-command):
    rm *

- Change version of the LM in the file MI_attributes:
    cd ..                      (go to LM_AXG561-DicosKernel or DicosKernel_LM)
    textedit MI_attributes &   (Or use another editor)
    - Verify that the version of the LM, e.g. <Version>R1G01</Version>,
      corresponds to what is loaded in the TelORB system to be upgraded.
    - Add e.g. the letter T (Test) to the version of the LM, e.g.
      <Version>R1G01T</Version>, save the file without changing its
      name, and exit)
  cd ..                        (Go to directory testLMs)

- Verify that no epconfig settings are set:
    epconfig l -v                     (Show all epconfig settings)

- Set epconfig settings towards the LM to be upgraded (if several LMs are to be
  created/built, it is possible to set epconfig settings towards all of them
  here):
    If the test LM was fetched from an AD release:
      epconfig s LM_AXG561-DicosKernel/

    or if the test LM was fetched from a patch release:
      epconfig s DicosKernel_LM/

- Build the new test LM "LM/AXG561" (if several LMs are to be built, it is
  possible to build all of them here):
    If the test LM was fetched from an AD release:
      epbuild -T i486 LM_AXG561-DicosKernel/

    or if the test LM was fetched from a patch release:
      epbuild -T i486 DicosKernel_LM/

    The building looks something like this if the test LM was fetched from an
    AD release:
      uabs31i1c50% epbuild -T i486 LM_AXG561-DicosKernel
      os is SunOS
      version is 5.6
      machine is sun4u

      Building LM/AXG561 /home/dicostest/tosFiles/to8/ad12.4/testLMs/LM_AXG561-DicosKernel
      epbuild: WARNING, SystemCall_SWI referred to from driver load module
      gcc-i386 -m486 -o bin/DicosKernel.LM_AXG561.elf.R1G06T.i486 -nostartfiles -static -Wl,-Ur -Wl,-d -Wl,-noinhibit-exec /ipims_dicos/BS2/eptools7/lib/crti486b.o ... /ipims_dicos/ipims_dicos20/BS2/tbAD12/DICOS_SA/ExecutionEnvironment_SE/BasicLibrary_SWCLib/StdLib_SCC/obj.i486/SCC_MD3.a /ipims_dicos/BS2/eptools7/lib/crti486e.o
      bin/DicosKernel.LM_AXG561.Code.R1G06T.i486 generated
      bin/DicosKernel.LM_AXG561.elf.R1G06T.i486.dxl generated

    The building looks something like this if the test LM was fetched from a
    patch release:
      os is SunOS
      version is 5.6
      machine is sun4u

      Building LM/AXG561 /home/dicostest/systest/ad/ad12.4p2/testLMs/DicosKernel_LM
      epbuild: WARNING, SystemCall_SWI referred to from driver load module
      gcc-i386 -m486 -o bin/DicosKernel.LM_AXG561.elf.AD124p2T.i486 -nostartfiles -static -Wl,-Ur -Wl,-d -Wl,-noinhibit-exec /ipims_dicos/BS2/eptools7/lib/crti486b.o ... /ipims_dicos/ipims_dicos20/BS2/tbAD12/DICOS_SA/ExecutionEnvironment_SE/BasicLibrary_SWCLib/StdLib_SCC/obj.i486/SCC_MD3.a /ipims_dicos/BS2/eptools7/lib/crti486e.o
      bin/DicosKernel.LM_AXG561.Code.AD124p2T.i486 generated
      bin/DicosKernel.LM_AXG561.elf.AD124p2T.i486.dxl generated

    It is OK to get the following printout:
      Use of uninitialized value at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/scripts/epbuild line 1662.

- Return to the upgrade section to proceed with the upgrade, or continue below if
  further test LMs are to be built.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Create test LM for "JavaMain" to test redundancy upgrade of a Java LM
- Go to the directory where the test LM will be put, e.g.
  cd /home/dicostest/systest/ad/ad12.4/testLMs/     (Adjust AD to valid release)

- Copy the LM from the AD release or from the patch release (or TB) that the
  TelORB system to be upgraded is loaded with, as exemplified below:
    If the test LM is to be fetched from an AD release:
      cp -r /ipims_dicos/ipims_dicos10/dists/TelORB-AD12.4/system/runtime/IDP_MD18-Java/LM_MD48-JavaMain/ .
        (Adjust AD to valid release)
    or if the test LM is to be fetched from a patch release:
      cp -r /ipims_dicos/ipims_dicos10/dists/AD12.4-patch/official/patch1/JavaMain_LM/ .
        (Adjust AD to valid release and patch to valid patch package)

- Proceed by following the instructions above for when creating a test LM for
  DicosKernel, but substitute the DicosKernel specific parts to JavaMain
  specific parts (and, of course, disregard the copying part in the
  beginning).

Hints
-----
set path = (/ipims_dicos/BS2/pub/jdk/bin $path)

epbuild -T i486 LM_MD48-JavaMain  (Create/build the test LM "JavaMain.LM_MD48")
                                  (Since there is a bug in the epbuild command,
                                   it might be that the LM is generated several
                                   times. However, no error messages should be
                                   received)

-- -- -- -- -- --
IDP/MD18 is renamed to CXP901309/1 in TSP5.
  (CXP901309/1;  // Java_IDP,  Java VM for Dicos (Optional))

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Create test LMs for "DemoApp" and "DemoTG" to test smooth upgrade of C++ LMs
Both test LMs will later be upgraded in one go.

- Go to the directory where the test LMs will be put, e.g.
  cd /home/dicostest/systest/ad/ad12.4/testLMs/     (Adjust AD to valid release)

- Copy the LMs from the AD release or from the patch release (or TB) that the
  TelORB system to be upgraded is loaded with, as exemplified below:
    If the test LMs are to be fetched from an AD release:
      cp -r /ipims_dicos/ipims_dicos10/dists/TelORB-AD12.4/system/runtime/IDP_DEA9990-Demo_IDP/LM_DEA9980-DeApp_App/ .
        (Adjust AD to valid release)
      cp -r /ipims_dicos/ipims_dicos10/dists/TelORB-AD12.4/system/runtime/IDP_DEA9990-Demo_IDP/LM_DEA9981-DeApp_TG_LM/ .
        (Adjust AD to valid release)

- Proceed by following the instructions above for when creating a test LM for
  DicosKernel, but substitute the DicosKernel specific parts to DemoApp and
  DemoTG specific parts, respectively (and, of course, disregard the copying
  part in the beginning).

    Get Swedish printouts instead of English printouts in DemoTG
    ------------------------------------------------------------
    Note:
    The instructions below are outdated and may be updated in the future.

    These instructions will modify the demo traffic generator so that Swedish
    printouts are generated instead of English ones.
    cp -r /home/dicoshack/Hack/uabvak/tb38.3/Patches/DemoTG_OU.R2/ .
    cp -r /home/dicoshack/Hack/uabvak/tb38.3/Patches/DemoTG_LM.R2/ .

    cd DemoTG_LM.R2/bin
    rm *
    cd ../../DemoTG_OU.R2/
    rm -r obj*

    cd src
    Edit the source code in DeAppTrafficGenerator.cc

    cd ..
    Change version of the LM in the file MI_attributes.

    cd ..
    epconfig s DemoTG_OU.R2/ DemoTG_LM.R2/
    epbuild -T i486 DemoTG_LM.R2

    Return to the upgrade section to proceed with the upgrade, or continue
    below if further test LMs are to be built.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Create test LM for "JavaDemo" to test smooth upgrade of a Java LM
- Go to the directory where the test LM will be put, e.g.
  cd /home/dicostest/systest/ad/ad12.4/testLMs/     (Adjust AD to valid release)

- Copy the LM from the AD release (or TB) that the TelORB system to be upgraded
  is loaded with, as exemplified below:
    If the test LM is to be fetched from an AD release:
      cp -r /ipims_dicos/ipims_dicos10/dists/TelORB-AD12.4/system/runtime/IDP_D1-JavaDemo/LM_D2-JavaDemo/ .
        (Adjust AD12.4 to valid release)

    or if the test LM is to be fetched from a testbed (not further described in
    this section):
      cp -r /ipims_dicos/ipims_dicos20/BS2/tbAD9.05/TEST_IDPG/JavaDemo_IDP/JavaDemo_LM/ .
        (Adjust tbAD9.05 to valid release)

- Proceed by following the instructions above for when creating a test LM for
  DicosKernel, but substitute the DicosKernel specific parts to JavaDemo
  specific parts (and, of course, disregard the copying part in the
  beginning).

Hints
-----
set path = (/ipims_dicos/BS2/pub/jdk/bin $path)

epbuild -T i486 JavaDemo_LM       (Create/build the test LM "JavaDemo_LM")
                                  (Since there is a bug in the epbuild command,
                                   it might be that the LM is generated several
                                   times. However, no error messages should be
                                   received)

Instructions
The error, which will cause cyclic zone reloads, will be introduced in LM
`ConfigManagerAgent.LM_AXG673'.
The faulty LM does not affect initial load nor reloads of single TelORB
processors.

    I have prepared an erroneous version of the LM ConfigManagerAgent.LM_AXG673
    for R13 with version R1H01, which is located at
    /home/dicostest/systest/AD13/test_programs/backdoor_upgrade/
    (ConfigManagerAgent_LM/bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486).
    Either use this LM or prepare an erroneous LM yourself by following the
    instructions below.

- Check the version of LM ConfigManagerAgent.LM_AXG673 in the TelORB system by
  either using the TelORB Manager/Browser, or by logging in to IO processor 1
  or 2 as follows:
    telnet toXio1                     (Log in to IO processor 1. Adjust toX to
                                       valid TelORB system or use IP address)
    login: telorb                     (Type user name)
    Password:                         (Type password)
    ls -l /opt/telorb/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/
  Make a note of the version of ConfigManagerAgent.LM_AXG673.Code.Rxxxx.i486
  (for R13, ConfigManagerAgent.LM_AXG673.Code.R1H01.i486, i.e. version R1H01).

- In a local shell, (create and) go to a directory which later will host the
  faulty LM, e.g.
    cd /home/telorb/users/uabxxx/backdoor/   (user telorb - su telorb)
    or e.g.
    cd /home/uabxxx/backdoor/

- Prepare the faulty LM as follows:

    - Source Envsettings from the testbed that corresponds to the correct LM
      version of ConfigManagerAgent.LM_AXG673 (adjust tbAD13.4b to valid test
      bed version in the path below):
        setenv EP_WORKSPACE `pwd`
        source /ipims_dicos/ipims_dicos20/BS2/tbAD13.4b/IP_CONF_INFO/EnvSettings
         ( Example of printout:
           CHIPSY Tools on s5s from chipsy_v16.032 Version 16.032.
           Done! )

    - Get the path to the faulty LM in the design environment:
        epgetpath LM/AXG673
         ( Example of printout:
         /ipims_dicos/BS2/tbAD13/DICOS_IDPG/Dicos_IDP/ConfigManagerAgent_LM )

    - Check LM identity and version (use the path from epgetpath above):
        more /ipims_dicos/BS2/tbAD13/DICOS_IDPG/Dicos_IDP/ConfigManagerAgent_LM/MI_attributes
                                        (Adjust tbAD13 to valid testbed version)
        The LM identity is found within the Identity tags, i.e.
        <Identity>LM/AXG673</Identity>.
        The LM version is found within the Version tags, e.g.
        <Version>R1H01</Version>.
      Verify that the version corresponds to the version of
      ConfigManagerAgent.LM_AXG673 that was previously checked on the IO
      processor.

    - Check related OU identity which is found in the same MI_attributes file as
      viewed above:
        The OU identity is found within the Includes.R.SWU tags, i.e.
          <Includes.R.SWU>OU/AXG2157</Includes.R.SWU>
        (It is also possible to fetch this information by using the epfollow
        command, i.e. epfollow LM/AXG673)

    - Get the path to the OU in the design environment, i.e.:
        epgetpath OU/AXG2157
         ( Example of printout:
           /ipims_dicos/BS2/tbAD13/DICOS_SA/SoftwareSupport_SE/ConfigurationManager_OB/ConfigManagerAgent_OU

    - Check OU identity and version (use the path from epgetpath above):
        more /ipims_dicos/BS2/tbAD13/DICOS_SA/SoftwareSupport_SE/ConfigurationManager_OB/ConfigManagerAgent_OU/MI_attributes
                                        (Adjust tbAD13 to valid testbed version)
        The OU identity is found within the Identity tags, i.e.
        <Identity>OU/AXG2157</Identity>.
        The OU version is found within the Version tags, e.g.
        <Version>R1K01</Version>.

    - Checkout the ConfigManagerAgent LM and OU from the repository:
        epsiadm export -r R1H01 LM/AXG673     (Adjust R1H01 to valid LM version)
         ( Example of printout:
           cvs export -r nLM/AXG673_R1H01 LM/AXG673_R
           cvs export: Updating ConfigManagerAgent_LM
           U ConfigManagerAgent_LM/.MI_checksum
           U ConfigManagerAgent_LM/MI_attributes )

        epsiadm export -r R1K01 OU/AXG2157    (Adjust R1K01 to valid OU version)
         ( Example of printout:
           cvs export -r nOU/AXG2157_R1K01 OU/AXG2157_R
           cvs export: Updating ConfigManagerAgent_OU
           cvs export: Updating ConfigManagerAgent_OU/cert
           cvs export: Updating ConfigManagerAgent_OU/doc
           cvs export: Updating ConfigManagerAgent_OU/src
           U ConfigManagerAgent_OU/.MI_checksum
           U ConfigManagerAgent_OU/Imakefile
           U ConfigManagerAgent_OU/MI_attributes
           U ConfigManagerAgent_OU/README
           U ConfigManagerAgent_OU/src/DswcmaCentralDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaCentralDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaCmSetupSupervisor.cc
           U ConfigManagerAgent_OU/src/DswcmaCmSetupSupervisor.hh
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.cc
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.hh
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.icc
           U ConfigManagerAgent_OU/src/DswcmaConstants.hh
           U ConfigManagerAgent_OU/src/DswcmaDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaDistributionPort.cc
           U ConfigManagerAgent_OU/src/DswcmaDistributionPort.hh
           U ConfigManagerAgent_OU/src/DswcmaDynamicKeyedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDynamicKeyedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaDynamicReplicatedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDynamicReplicatedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaInstallationPort.cc
           U ConfigManagerAgent_OU/src/DswcmaInstallationPort.hh
           U ConfigManagerAgent_OU/src/DswcmaInstalledDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaInstalledDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaLoadingManager.cc
           U ConfigManagerAgent_OU/src/DswcmaLoadingManager.hh
           U ConfigManagerAgent_OU/src/DswcmaProcessData.cc
           U ConfigManagerAgent_OU/src/DswcmaProcessData.hh
           U ConfigManagerAgent_OU/src/DswcmaProcessManager.cc
           U ConfigManagerAgent_OU/src/DswcmaProcessManager.hh
           U ConfigManagerAgent_OU/src/DswcmaReplicatedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaReplicatedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaStarter.cc )

      To get epsiadm help, either enter the command epsiadm or go to
      TelORB commands and scripts.

      Note: To be able to checkout LMs from the TelORB repository and to use the
      TelORB build environment, you have to be part of the group `dicosadm'.
      (Alexander Larruy and Anders Franzén are the owners of the group and are
      the ones to approve changes to the group.)

    - Go to the src directory for the OU, e.g.
        cd ConfigManagerAgent_OU/src/

    - Open DswcmaConfigurationManagerAgentControl.cc in a texteditor.
      Find the variable zProcReload and insert the string `assert (0);' so that
      the code will look something like this:

	  case ZoneReload:
	    {
	      this->dbStart->startBase2Sequence (DdbCmaStart::zProcReload, identity);
	      assert(0);
	      break;
	    }

      Save the file without changing its name.

    - If you will include this LM in a backdoor upgrade later on, do not modify
      the version of the LM. Otherwise modify the version as follows:
      Open
      /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/MI_attributes
      (Adjust path) in a texteditor.
      Add e.g. the string `faulty' to the version of the LM, so that the version
      line will look something like this:
        <Version>R1H01faulty</Version>.
      Save the file without changing its name.

- Compile and link (epbuild) the faulty version of the LM:
    - Set necessary epconfig settings towards the OU and LM:
        cd ../..                         (Go back to the working directory, e.g.
                                          /home/telorb/users/uabxxx/backdoor/)
        epconfig s ConfigManagerAgent_OU/
         ( Example of printout:

           Use of uninitialized value at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/lib/Eplib.pm line 147.
           epconfig: OU/AXG2157 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_OU added )

        epconfig s ConfigManagerAgent_LM/
         ( Example of printout:
           Use of uninitialized value at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/lib/Eplib.pm line 147.
           epconfig: LM/AXG673 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM added )

    - Verify that epconfig settings are only set to
        LM/AXG673 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM
        OU/AXG2157 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_OU
        epconfig l -v

    - Build the new LM:
        epbuild -T i486 ConfigManagerAgent_OU ConfigManagerAgent_LM/
         ( Example of printout:
           os is SunOS
           version is 5.6
           machine is sun4u

           Building OU/AXG2157 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_OU
             :

           Building LM/AXG673 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM
             :
           bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 generated )

      (It is OK to get the following printouts:
       Probable precedence problem on logical and at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/scripts/epbuild line 333.
       and
       Use of uninitialized value at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/scripts/epbuild line 1662.)

    - The file ConfigManagerAgent.LM_AXG673.Code.R1H01faulty.i486 or
      ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 is generated
      below e.g. /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/bin/
      (the bin directory did not previously exist).

The erroneous LM is now ready.

If the LM is to be used for a backdoor upgrade, perform an initial load with an
epconfig setting towards the erroneous LM, e.g.
  epconfig s /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/
Or if it is to be fetched from my prepared directory for R13 (Version R1H01):
  epconfig s /home/dicostest/systest/AD13/test_programs/backdoor_upgrade/ConfigManagerAgent_LM/.
Thereafter create a backup and perform a zone reload, which now will result in
cyclic zone reloads.

The erroneous LM may be included in an upgrade package.
  (epconfig set towards e.g.
  /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/
  when building the upgrade package.)
When applying the upgrade package, the redundancy upgrade method will be used.
After the upgrade, simply perform a zone reload to get cyclic zone reloads.

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions - Find out which LM that is faulty. - Check version and size of the faulty LM on either IO processor 1 or 2. - Export the faulty (old) LM and OU from the repository. - Use the exported LM to prepare a new LM (that later will substitute the faulty LM), i.e. make necessary corrections and include the string constant `ldupatch123456789012345' in the new LM. Keep the old version number. Save with the same name. - Compile and link the new LM using `epconfig set' towards the OU and LM, and thereafter `epbuild'. The size of the LM may not more than double. - Fetch the script lduPatch. - Fetch the old (faulty) LM. - Rename the old LM to `x.Code.y.old'. - Fetch the new (corrected) LM. - Check checksums of old and new LMs using lduReverse. - Use the script lduPatch to split and concatenate the LMs as follows: o lduPatch -s x.Code.y.old (Split header & body of old LM to separate files) o lduPatch -s x.Code.y (Split header & body of new LM to separate files) o cat x.Code.y.old.header x.Code.y.body > x.Code.y (Concatenate the header of the old LM and the body of the new LM) o lduPatch -c x.Code.y (Manipulate the string constant `ldupatch123456789012345' so that the new LM gets the same checksum as the old LM) - Replace the old LM with the new LM on IO processors 1 and 2.

General
There is a method to upgrade software in case it is not possible to use the
ordinary upgrade functionality, e.g. in case of cyclic zone reloads.
This method is called Backdoor upgrade and comprises of what is mentioned in the
"Shortcut description" box above. For a more detailed description, see
section "Instructions" below.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Instructions
Note: In the examples below, I'm using the LM `ConfigManagerAgent.LM_AXG673'
      as the scapegoat LM.
      Therefore, be sure to substitute all LM related parts with what is valid
      for the TelORB system that you are running.
 
- Find out which LM that is faulty, i.e. which LM that e.g. causes the cyclic
  zone reloads or inhibits the ordinary upgrade functionality from being used.
  One way of doing this is to check the TelORB processor consoles (or logs).
  Another way is to check the error dumps and to interpret the suspected dump
  by using the command epelfaddr.
  In these instructions, the faulty LM is
  ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 with version R1H01.

    I have prepared an erroneous version of the LM ConfigManagerAgent.LM_AXG673
    for R13 with version R1H01, which is located at
    /home/dicostest/systest/AD13/test_programs/backdoor_upgrade/
    (ConfigManagerAgent_LM/bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486).

  If you want to introduce an error in LM ConfigManagerAgent.LM_AXG673 which
  causes cyclic zone reloads, simply follow the instructions in section
  Create test LM which causes cyclic zone reloads above.

- Log in to IO processor 1 or 2 and check the version and size of the faulty LM:
    telnet toXio1                     (Log in to IO processor 1. Adjust toX to
                                       valid TelORB system or use IP address)
    login: telorb                     (Type user name)
    Password:                         (Type password)
    ls -l /opt/telorb/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/
                                       (Adjust Dicos.IDP_MD14 to valid IDP name)
    Make a note of the version and size of the faulty LM (e.g.
    ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 with version R1H01 and size 
    148080 bytes).

- In a local shell, (create and) go to a directory which later will host the
  faulty and corrected LMs, as well as the script lduPatch. This script will be
  used to get the same checksum in the corrected LM as that of the faulty LM.
  This is important, since the checksum of the LM is also stated in the
  bootLoadTable.0 file (e.g. /opt/telorb/axe/loadingGroup01_1/Processor1) for
  each TelORB processor and these files are used when reloading TelORB
  processors.
  E.g.
    cd /home/telorb/users/uabxxx/backdoor/   (user telorb - su telorb)
    or e.g.
    cd /home/uabxxx/backdoor/

- Prepare a new LM (see below), that later will substitute the faulty LM, i.e.
  make necessary corrections and also include the string constant
  `ldupatch123456789012345' in the .cc file, i.e.
  `static const char* ldupatch = "ldupatch123456789012345";'.
  The version of the LM must not be modified.
  To prepare the new LM, follow the following instructions:

    - Source Envsettings from the testbed that corresponds to the faulty LM
      (adjust tbAD13.4b to valid testbed version in the path below):
        setenv EP_WORKSPACE `pwd`
        source /ipims_dicos/ipims_dicos20/BS2/tbAD13.4b/IP_CONF_INFO/EnvSettings
         ( Example of printout:
           Done!
           CHIPSY Tools on s5s from chipsy_v16.032 Version 16.032. )

    - Get the path to the faulty LM in the design environment:
        epgetpath LM/AXG673                       (Adjust LM/AXG673 to valid LM)
         ( Example of printout:
           /ipims_dicos/BS2/tbAD13/DICOS_IDPG/Dicos_IDP/ConfigManagerAgent_LM

    - Check LM identity and version:
        more /ipims_dicos/BS2/tbAD13/DICOS_IDPG/Dicos_IDP/ConfigManagerAgent_LM/MI_attributes
                             (Adjust tbAD13, Dicos_IDP and ConfigManagerAgent_LM
                              to valid testbed, IDP and LM)
        The LM identity is found within the Identity tags, e.g.
        <Identity>LM/AXG673</Identity>.
        The LM version is found within the Version tags, e.g.
        <Version>R1H01</Version>.
      Verify that the version corresponds to the version of the faulty LM
      previously checked on the IO processor.

    - Check related OU identity which is found in the same MI_attributes file as
      viewed above:
        The OU identity is found within the Includes.R.SWU tags, e.g.
        <Includes.R.SWU>OU/AXG2157</Includes.R.SWU>
        (It is also possible to fetch this information by using the epfollow
        command, e.g. epfollow LM/AXG673 (Adjust LM/AXG673 to valid LM))

    - Get the path to the OU in the design environment, e.g. (use OU identity):
        epgetpath OU/AXG2157                     (Adjust OU/AXG2157 to valid OU)
         ( Example of printout:
           /ipims_dicos/BS2/tbAD13/DICOS_SA/SoftwareSupport_SE/ConfigurationManager_OB/ConfigManagerAgent_OU )

    - Check OU identity and version (use the path from epgetpath above):
        more /ipims_dicos/BS2/tbAD13/DICOS_SA/SoftwareSupport_SE/ConfigurationManager_OB/ConfigManagerAgent_OU/MI_attributes
                                        (Adjust tbAD13 to valid testbed version)
        The OU identity is found within the Identity tags, i.e.
        <Identity>OU/AXG2157</Identity>.
        The OU version is found within the Version tags, e.g.
        <Version>R1K01</Version>.

    - Checkout the faulty LM and OU from the repository, e.g. for the
      ConfigManagerAgent LM and OU:
        (Note that if you are testing the backdoor upgrade function, do not
        checkout the LM and OU from the repository. Instead, use the LM and OU
        (e.g. ConfigManagerAgent_LM and ConfigManagerAgent_OU, and directories
        below) that you previously prepared to cause e.g. the cyclic zone
        reloads.)

        epsiadm export -r R1H01 LM/AXG673     (Adjust R1H01 to valid version and
                                               adjust LM/AXG673 to valid LM)
         ( Example of printout:
           cvs export -r nLM/AXG673_R1H01 LM/AXG673_R
           cvs export: Updating ConfigManagerAgent_LM
           U ConfigManagerAgent_LM/.MI_checksum
           U ConfigManagerAgent_LM/MI_attributes )

        epsiadm export -r R1K01 OU/AXG2157    (Adjust R1K01 to valid version and
                                               adjust OU/AXG2157 to valid OU)
         ( Example of printout:
           cvs export -r nOU/AXG2157_R1K01 OU/AXG2157_R
           cvs export: Updating ConfigManagerAgent_OU
           cvs export: Updating ConfigManagerAgent_OU/cert
           cvs export: Updating ConfigManagerAgent_OU/doc
           cvs export: Updating ConfigManagerAgent_OU/src
           U ConfigManagerAgent_OU/.MI_checksum
           U ConfigManagerAgent_OU/Imakefile
           U ConfigManagerAgent_OU/MI_attributes
           U ConfigManagerAgent_OU/README
           U ConfigManagerAgent_OU/src/DswcmaCentralDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaCentralDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaCmSetupSupervisor.cc
           U ConfigManagerAgent_OU/src/DswcmaCmSetupSupervisor.hh
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.cc
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.hh
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.icc
           U ConfigManagerAgent_OU/src/DswcmaConstants.hh
           U ConfigManagerAgent_OU/src/DswcmaDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaDistributionPort.cc
           U ConfigManagerAgent_OU/src/DswcmaDistributionPort.hh
           U ConfigManagerAgent_OU/src/DswcmaDynamicKeyedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDynamicKeyedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaDynamicReplicatedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDynamicReplicatedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaInstallationPort.cc
           U ConfigManagerAgent_OU/src/DswcmaInstallationPort.hh
           U ConfigManagerAgent_OU/src/DswcmaInstalledDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaInstalledDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaLoadingManager.cc
           U ConfigManagerAgent_OU/src/DswcmaLoadingManager.hh
           U ConfigManagerAgent_OU/src/DswcmaProcessData.cc
           U ConfigManagerAgent_OU/src/DswcmaProcessData.hh
           U ConfigManagerAgent_OU/src/DswcmaProcessManager.cc
           U ConfigManagerAgent_OU/src/DswcmaProcessManager.hh
           U ConfigManagerAgent_OU/src/DswcmaReplicatedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaReplicatedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaStarter.cc )

      To get epsiadm help, either enter the command epsiadm or go to
      TelORB commands and scripts.

      Note: To be able to checkout LMs from the TelORB repository and to use the
      TelORB build environment, you have to be part of the group `dicosadm'.
      (Alexander Larruy and Anders Franzén are the owners of the group and are
      the ones to approve changes to the group.)

    - Go to the src directory for the OU, e.g.
        cd ConfigManagerAgent_OU/src/ (Adjust ConfigManagerAgent_OU to valid OU)

    - Make necessary corrections in the faulty .cc and/or .hh file below the src
      directory of the OU (e.g. LoadLinkDriver_OU/src/) and also include the
      string constant 'ldupatch123456789012345' in the modified .cc or .hh file,
      i.e. include the following line:
        static const char* ldupatch = "ldupatch123456789012345";

      It is possible to correct several .cc and .hh files in the OU. In this
      case it is only necessary to include the string constant in one of the
      corrected .cc or .hh files.
   
- Compile and link (epbuild) the new version of the LM with the same version
  as it had before (its size may not more than double), e.g.:
    - Set necessary epconfig settings towards the OU and LM:
        cd ../..                         (Go back to the working directory, e.g.
                                         /home/telorb/users/uabxxx/backdoor/)
        epconfig s ConfigManagerAgent_OU/ (Adjust ConfigManagerAgent_OU to valid OU)
         ( Example of printout:
           Use of uninitialized value at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/lib/Eplib.pm line 147.
           epconfig: OU/AXG2157 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_OU added )

        epconfig s ConfigManagerAgent_LM/ (Adjust ConfigManagerAgent_LM to valid LM)
         ( Example of printout:
           Use of uninitialized value at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/lib/Eplib.pm line 147.
           epconfig: LM/AXG673 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM added )

    - Build the new LM:
        epbuild -T i486 ConfigManagerAgent_OU ConfigManagerAgent_LM/
                                      (Adjust ConfigManagerAgent_OU and
                                       ConfigManagerAgent_LM to valid OU and LM)
                                      ("-t i486" is not necessary)
         ( Example of printout:
           os is SunOS
           version is 5.6
           machine is sun4u

           Building OU/AXG2157 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_OU
             :
           Building LM/AXG673 /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM

             :
           bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 generated )

      (It is OK to get the following printouts:
       Probable precedence problem on logical and at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/scripts/epbuild line 333.
       and
       Use of uninitialized value at /ipims_dicos/BS2/devenv2.0/DevEnv_IDPG/Tools_IDP/ToolsLib_LM/scripts/epbuild line 1662.)

    - The file ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 (example) is
      generated below
      /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/bin/
      (this directory did not previously exist).
      This is the file that you will later use as a  substitute for the faulty
      LM, but first the checksum of the new LM must be manipulated so that the
      new LM gets the same checksum as that of the faulty LM. This is important,
      since the checksum of the LM is also stated in the bootLoadTable.0 file
      for each TelORB processor, and these files are used when reloading TelORB
      processors. The checksum is manipulated by using the script lduPatch as
      described below.
      (To check the checksums for an LM's header and body, respectively, enter
      the command lduReverse followed by the LM to check, e.g.
        lduReverse /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486   (Adjust LM))

- Verify that the new string constant `ldupatch123456789012345' is included in
  the new LM:
    strings ConfigManagerAgent_LM/bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 | grep ldupatch
      ( Printout if OK:
        ldupatch123456789012345
        ldupatch )
      ( No printout if NOK )

- Fetch the script lduPatch:
    which lduPatch                  (Check where to fetch lduPatch from, i.e. it
                                     will be fetched from the source location)
    cp /ipims_dicos/BS2/tbAD13.3b/DICOS_IDPG/Unix_IDP/UnixLib_LM/devenv_scripts/lduPatch .
                                   (Use the path from the `which' command above)

- Fetch the old (faulty) LM from the release location (distribution) (or from
  (IO processor):
    (Note that if you are testing the backdoor upgrade function, do not
    fetch the LM from the release location. Instead, use the LM
    (e.g. ConfigManagerAgent.LM_AXG673.Code.R1H01.i486) that you previously
    prepared to cause e.g. the cyclic zone reloads.)

    cp /ipims_dicos/ipims_dicos10/dists/TelORB-R13/system/runtime/IDP_MD14-Dicos/LM_AXG673-ConfigManagerAgent/bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 .
                            (Adjust line to be valid for correct release and LM)

- Rename the old LM to `x.Code.y.old', e.g.:
    mv x.Code.y x.Code.y.old   (E.g.
      mv ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 ConfigManagerAgent.LM_AXG673.Code.R1H01.i486.old)

- Fetch the new LM:
    cp /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 .
                                        (Adjust line to be valid for correct LM)

- Verify that the size of the new LM has not increased by a factor greater than
  2 compared to the size of the old LM:
    ls -l

- Make a note of the checksumHeader and checksumBody of both the old and new LMs:
    lduReverse x.Code.y.old   (E.g. lduReverse ConfigManagerAgent.LM_AXG673.Code.R1H01.i486.old)
    lduReverse x.Code.y       (E.g. lduReverse ConfigManagerAgent.LM_AXG673.Code.R1H01.i486)
  The printout "the relocatable Module is OK" should also be obtained for both
  lduReverse commands (the word "relocatable" may vary).
 
- Split the old LM, i.e. write header & body to separate files:
    lduPatch -s x.Code.y.old   (E.g. lduPatch -s ConfigManagerAgent.LM_AXG673.Code.R1H01.i486.old)

- Split the new LM, i.e. write header & body to separate files:
    lduPatch -s x.Code.y       (E.g. lduPatch -s ConfigManagerAgent.LM_AXG673.Code.R1H01.i486)

- Concatenate the header of the old LM and the body of the new LM:
    cat x.Code.y.old.header x.Code.y.body > x.Code.y  (E.g. cat ConfigManagerAgent.LM_AXG673.Code.R1H01.i486.old.header ConfigManagerAgent.LM_AXG673.Code.R1H01.i486.body > ConfigManagerAgent.LM_AXG673.Code.R1H01.i486

- Verify that the checksumHeader and checksumBody of the new LM are the same as
  those of the old LM:
    lduReverse x.Code.y   (E.g. lduReverse ConfigManagerAgent.LM_AXG673.Code.R1H01.i486)
  The printout "Bad checksum of Module body" should also be obtained.

- Manipulate the constant string `ldupatch123456789012345' of the new LM so that
  the body of the new LM gets the same checksum as specified in `checksumBody'
  of the new (and old) LM:
    lduPatch -c x.Code.y           (E.g. lduPatch -c ConfigManagerAgent.LM_AXG673.Code.R1H01.i486)

      ( Example of printout:
        Identity          LM/AXG673
        Revision          R1H01
        DebugInfo         ConfigManagerAgent.LM_AXG673.elf.R1H01.i486
        loadModuleLen     148080
        typeOfLoadModule  6
        targetProcessor   16
        checksumHeader    1447fc88 (340262024)
        checksumBody      b306ceea (-1291399446)
        ERROR: Incorrect body check-sum: 972db233 (expected b306ceea)
        Kernel configuration LM patched successfully )

- Verify that the checksumHeader and checksumBody of the new LM are the same as
  those of the old LM:
    lduReverse x.Code.y   (E.g. lduReverse ConfigManagerAgent.LM_AXG673.Code.R1H01.i486)

  The printout "the relocatable Module is OK" should also be obtained (the word
  "relocatable" may vary).

Now the new LM should be accepted for the old.

You now need to replace the faulty LM with the new LM on IO processors 1 and 2,
as described below.

- On IO processor 1:
  Substitute the old LM located at
  /opt/telorb/axe/loadingGroup01_1/codeArchive/IDP_of_faulty_LM/
  with the new LM as follows:
    cd /opt/telorb/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/   (Adjust
                                                line to be valid for correct LM)
    ls -l
    mv x.Code.y x.Code.y.old   (E.g. mv ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 ConfigManagerAgent.LM_AXG673.Code.R1H01.i486.old)
                               (In case anything goes wrong)
    ftp 134.138.186.xx                         (Set up ftp to a workstation from
                                                where the new LM is available)
    telorb                                      (Log in as telorb user)
    psw                                         (Type telorb password)
    cd /home/telorb/users/uabxxx/backdoor/      (Adjust path to where the new LM
                                                 is located)
    bin                                         (Enter binary transfer mode)
    get x.Code.y      (E.g. get ConfigManagerAgent.LM_AXG673.Code.R1H01.i486)
    bye               (Exit ftp)
    ls -lrt           (Verify that the new LM is successfully copied)
      (It is not necessary to remove the old LM, but if this is desired, do as
       follows: rm x.Code.y.old (E.g. rm ConfigManagerAgent.LM_AXG673.Code.R1H01.i486.old)

- On IO processor 2:
  Substitute the old LM located at
  /opt/telorb/axe/loadingGroup01_2/codeArchive/IDP_of_faulty_LM/
  with the new LM as follows:
    Same procedure as for IO processor 1 above, but use loadingGroup01_2
    instead of loadingGroup01_1.

- Depending on what state the TelORB system is in, take necessary actions to
  get the new LM in to the system, e.g. reload each TelORB processor where the
  faulty LM is loaded one by one (depending on the system state, it may also be
  appropriate to perform a zone reload). If the TelORB system is performing
  cyclic zone reloads, it should automatically be loaded after the faulty LM has
  been replaced.

- Verify, by using the TelORB Manager (Inventory card), that the LM exists in
  the TelORB system.
  Unfortunately, it is not possible to verify that the LM is changed by using
  the Inventory card in the TelORB Manager, since it will show the same version
  and size as that of the "old" LM.
  However, there is a way of checking that the LM is backdoor upgraded. To do
  so, do as follows on any of the IO processors:
    cd /opt/telorb/axe/loadingGroup01_1/codeArchive/Dicos.IDP_MD14/
                                       (Adjust Dicos.IDP_MD14 to valid IDP name)
    strings ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 | grep ldupatch
               (Adjust ConfigManagerAgent.LM_AXG673.Code.R1H01.i486 to valid LM)
      ( Printout if LM has been backdoor upgraded, e.g.:
        ldupatchA(AsA%Aq9$5q345
        ldupatch )
      ( No printout if LM is not backdoor upgraded )


Hints

- Get help text for lduPatch:

    ./lduPatch -h
      --- Start of printout ---
      Patches LM-headers, and re-computes checksum
      Syntax: ldupatch -[rhskcCd:i:v:f:t:p:] LM-file    (Should be lduPatch!!!)
         h     - This printout
         d #   - Debug printout level (0-silent, 9-verbose)
         i str - Set "Identity"
         v str - Set "Revision" (version)
         f str - Set "DebugInfo" (usually file name)
         t #   - Set "LmType" to the numeric value #
         p #   - Set "TargetProcessor" to the numeric value #
         k     - Patch kernelConf-body to match bodyCsum
         c     - Patch code loadmodule for non-upgrade patching
         C     - get instructions on 'c' option
         s     - Split. Write header&body to separate files
         r     - Re-compute checksums
         (sizeof(LmHeader) = 224 byte)
      --- End of printout ---


- If lduPatch does not work:

    uabs31i1c50% module avail

    **** The /home/telorb/modulefiles directory can not be opened for reading.

    --------- /opt/local/loginadm/modulefiles ---------



    --------- /opt/as/loginadm/modulefiles ---------
    aps        java1.2    lsf        pub        symon      
    hdesetup   java2      md         reossetup  workshop5  

    uabs31i1c50% gcc
    gcc: Command not found.
    uabs31i1c50% module add pub
    uabs31i1c50% module avail

    **** The /home/telorb/modulefiles directory can not be opened for reading.

    --------- /opt/local/loginadm/modulefiles ---------



    --------- /opt/as/loginadm/modulefiles ---------
    aps        java1.2    lsf        pub        symon      
    hdesetup   java2      md         reossetup  workshop5  

    uabs31i1c50% gcc -o lduPatch ldupatch.cc
    uabs31i1c50% ls
    CVS          lduPatch     ldupatch.cc
    uabs31i1c50% pwd
    /home/telorb/users/uabxxx/lduPatch/src
    uabs31i1c50% ls -l
    total 152
    drwxr-sr-x   2 telorb   uab          512 Jul 20 13:54 CVS
    -rwxr-xr-x   1 telorb   uab        55900 Jul 20 14:05 lduPatch
    -rw-r--r--   1 telorb   uab        19594 Jul 20 13:54 ldupatch.cc

== == == == == == == == == == == == == == == == == == == == == == == == == ==

One way of testing backdoor upgrade
- Introduce an error in LM ConfigManagerAgent.LM_AXG673 which will cause cyclic
  zone reloads, by following the instructions in section
  Create test LM which causes cyclic zone reloads above.
    I have prepared an erroneous version of the LM ConfigManagerAgent.LM_AXG673
    for R13 with version R1H01, which is located at
    /home/dicostest/systest/AD13/test_programs/backdoor_upgrade/
    (ConfigManagerAgent_LM/bin/ConfigManagerAgent.LM_AXG673.Code.R1H01.i486).

- Perform an initial load with an epconfig setting towards the erroneous LM, e.g.
    epconfig s /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/
  Or if the erroneous LM is to be fetched from my prepared directory for R13
  (Version R1H01):
    epconfig s /home/dicostest/systest/AD13/test_programs/backdoor_upgrade/ConfigManagerAgent_LM/.

- Create a backup.

- Perform a zone reload, which will result in cyclic zone reloads.

- Follow the section "Backdoor upgrade" in the TelORB O&M documentation
  for TelORB R13 or later, or follow the instructions in this section
  Backdoor upgrade above (which contains some tips to smooth up the test).

• General
• Initiation of network redundancy in Zone 1 (from R13)
• Initiation of network redundancy in Zone 2 and completion (from R13)
• Initiation of network redundancy in Zone 1 (upto AD12)
• Initiation of network redundancy in Zone 2 and completion (upto AD12)
• Initiation of partitioned network redundancy (siblings) after initiation of network redundancy (from R13)
• Get network redundancy state of a zone via WWW
• Get network redundancy mode of a zone
• Get network redundancy information for a zone via telnet
• Copy a backup from primary zone to standby zone by using tos1/tos2
• Check if and when the network redundancy links between the two zones have glitched
• Compare demo application data between two zones
• Zone reload of default standby zone (from AD12)
• Zone reload of default primary zone (upto AD11.4.1)
• Zone reload of default primary zone (from AD12)
• Zone reload of both zones (from AD12)
• Addition of DU suites (POTs)
• Removal of DU suites (POTs)
• List DU suites (POTs)
• External synchronization from old backup (upto AD11.4.1)
• Remote Sync: Quick sync (from AD12)
• Remote Sync: External sync (from AD12)
• Smooth TakeOver (from AD12)
• Unpleasant network redundancy states
• Disconnection of network redundancy link between zones
• Reload of TelORB processor in standby zone during external synchronization
• Chicago redundancy test cases
• Hints

The Network Redundancy solution adopted in TelORB is based on having two zones
where one is a primary and the other a standby zone. Any transactions that are
committed in the primary zone are propagated to the standby zone with TCP/IP.
This is done by configuring Distribution Unit Types (DUTs) as "netshared".

Reconciliation means that the time stamps of all netshared database objects are
compared between the primary and standby zones. If discrepancies between the two
zones are detected, the database in the standby zone is cleared before an
external synchronization is executed. If no discrepancies are detected, the
database is not cleared, but an external synchronization is executed.
A reconciliation always includes an external synchronization.

Reconciliation can only be initiated in two ways, either manually by clicking
the reconciliation button in the TelORB Browser (only allowed in standby zone
when it is in Down mode), or when an automatic network redundancy switchover
occurs.
In AD12, the possibility of performing a manual smooth switchover is introduced,
and in this case no reconciliation is required.

External synchronization means that the standby zone synchronizes its database
from the database in the primary zone. To accomplish this, a backup version
from the primary zone is copied to the standby zone, and is then used to update
the database objects in the standby zone. Only database objects set as netshared
are considered.

The "In queue:" printout in the consolelogs, indicates number of lost
transactions between the zones. There is no queue if the value for "In queue:"
is the same as the value for "(n untried in queue)".
One transaction can contain one or several objects.

The word `default' in `default primary zone' and `default standby zone' are
equivalent with the word `preferred' in the text below regarding netshared
redundancy zones.

Prior to AD12.4 (before the smooth TakeOver concept was introduced), after a
TakeOver in the default standby zone (Zone 2), a reconciliation has to be
performed in the new default standby zone (Zone 1) before a backup in the
new primary zone (Zone 2). The backup is then copied to the new default
standby zone (Zone 1).


Remote sync: Quick sync/External sync
-------------------------------------
In AD12, the function "remote sync" was introduced.
Remote sync implies that a "quick sync" is being performed and possibly also an
external sync, see below.
During a quick sync, differences in the netshared database objects between the
zones are searched for whilst a backup is being created in the primary zone.
The values of all differing objects are stored in the standby zone to be swapped
to when all objects have been searched through. The swap will only take place if
less than a certain amount of ojects (RSLimit = 30000 objects in AD12.3) differ
between the zones. If too many objects differ, an external sync is requested
which results in that the created backup is being sent over to the standby zone
and is being synchronized from.
If the quick sync fails, the remote sync function is ended.

One of the goals with quick sync is to quickly be able to restore the database
replication from a TelORB processor crash in the standby zone.

Remote sync is not initiated automatically without the Scheduler. To test remote
sync, click the TelORB Browser button "Start Remote Sync" in the primary zone.

Notification "External Sync Succeeded" info (valid from AD12):
InstalledObjects = no. of added objects minus no. of deleted objects.
UpdatedObjects = no. of changed objects.

Notification "Remote Sync Succeeded" info (valid from AD12):
NoOfDifferingObjects = no. of updated objects.

In R13, partitioned network redundancy was introduced and this changed the
remote sync behavior slightly. When partitioned network redundancy is initiated,
the normal procedure is now to execute traffic in both zones and this leads to
that remote sync will be performed in both zones. When both zones are in
NetShared mode and a remote sync is initiated in either of the zones, the
backup, that was previously automatically created in the other zone after the
syncing was successfully performed, is not created. This is due to that the
other zone will take its own backups when that zone performs remote syncing.
A backup (in the other zone after the syncing was successfully performed) will
still always be created if partitioned network redundancy is not initiated, or
if partitioned network redundancy is initiated and the zone where the remote
sync is started is in TakeOver mode and the other zone is in Down mode.

-- Start e-mail info from uababt, 000310: --
  There is an operation called RemoteSync that one can apply on a zone.
  This operation has the goal of ensuring that any and all standbys of this zone
  are in sync with this zone. The RemoteSync operation performs a backup and in
  parallel with the backup performs a quicksync with all standbys. The backup
  should always succeed. The quicksyncs may fail or succeed. In a future with
  more than two zones, some of the quicksyncs may fail and some may succeed. If
  a quicksync (with repect to some standbyzones fails) than the higher levels
  have the option of transmitting the backup (part or whole) to that
  zone and starting an external sync on that zone.

  One thing to clarify in the documentation is that RemoteSync is in our
  system always a "push" operation from a primary, whereas an external sync is
  always a "pull" operation into a standby. 
  With partitioned netred both zones will be both primary and standby (for
  different partitions) at the same time. 

  A successful RemoteSync will always mean that "my standby(s) are in  sync with
  me". It never means "I am in sync with my primar(ies)".

  An external sync succeeded notification is the reverse. It means "I am in
  synch with my primary(ies)" and never "my standby(s) are in synch with me".
-- End e-mail info from uababt. --


Remote sync environment data settings
-------------------------------------
In TelORB release R13p5-R13p6, the remote sync functionality was modified to be
able to handle a link with a small bandwidth (1.5Mbit on one T1 link).
LMC has succeeded to configure the router for load sharing on two T1 links and
can thereby get ~3MBit. However, it must be possible to transfer data on only
one of the links in case of link failure.

To test RemoteSynch on a 1.5MBit link, one must set a couple of parameters in
DicosEnvironment:

Explanation of some remote sync associated environment data:

- RSSendPolicy = 1, makes the remote sync synchronous and the backup time will
  be longer if ACKs are delayed.
  RSSendPolicy = 0, makes the remote sync asynchronous.

- RSMessageSize = 100 .. 65408, sets the maximum size of each message and must
  have as low value as possible as to not overload the network redundancy links
  (which in its turn will block traffic).
  On the other hand, if the value is set too low, the remote sync will take
  longer time and the links will not be utilized to their full extent.

- RSMaxMissingAcks = 1 sets the amount of outstanding ACKs to 1, i.e. a full
  synchronous protocol.

- RSAllowedDelay decides how long the waiting time for ACKs should be before
  giving up the remote sync and finishes the backup without the remote sync
  (and answers "backup transfer needed").
  LMC tried 300 000, i.e. 5 min, which worked fine (R13p5), but this value seems
  a little bit high. However, it does not matter if the value is too high, the
  only disadvantage is that one has to wait a little bit longer for the backup
  to finish in case of network redundancy link problems.
  Can be set to a higher value, if a timeout is received during remote sync. 

- RSLimit decides how many objects one tries to compensate (update) in a
  QuickSynch transaction.
  (Can be adjusted, if "User heap exhausted" dump is received. Too much on
  heap.)

- PpClientTimeout is a new parameter (in R13) which was introduced to inhibit
  the PpClient to disconnect too easily.
  If this value is set to a higher value, the network redundancy links will be
  slower in discovering errors and switch over to the other redundant link.

Default settings in R13p5:
  RSMessageSize = 65408
  RSAllowedDelay = 60000
  RSCompensationDelay = 120000
  RSPriority = NormalPriority
  RSMaxMissingAcks = 2
  RSLimit = 30000
  RSSendPolicy = 1
  PpClientTimeout = 1000

Changes of the RS... parameters are activated when the next remote sync starts.
A change of the parameter PpClientTimeout is activated by bringing the network
redundancy links down and up by either disconnecting and reconnecting them or by
deactivating and activating them via the TelORB Manager.


Alarm "Reconciliation Needed"
-----------------------------
The alarm "Reconciliation Needed" that was introduced in AD12, may be received
at three occasions:
1. Zone reload of both zones. The alarm appears in both zones. The alarm should
   not appear if only one of the zones are reloaded.
2. Perform a TakeOver in the default standby zone. The alarm appears in the
   default primary zone.
3. Disconnect the network redundancy link between the zones and connect it.
   (Not yet verified.)


TelORB Browser buttons "Get Status" and "Is working?"
-----------------------------------------------------
The TelORB Browser(5.4) for AD12 has two buttons called "Get Status" and "Is
working?":
"Get Status" (Inactive/Active): Contolled by activating/deactivating the network
redundancy link. Operator initiated status.
"Is working?" (No/Yes): The network redundancy link must be up and TCP/IP
established to get "Yes". "Actual state".


Further network redundancy information for AD12
-----------------------------------------------
Sequences for Reconciliation

(Source: Created by Stefan Näslund.)


Partitioned network redundancy (PNR)
------------------------------------
Partitioned network redundancy was introduced in R13.
Partitioned network redundancy makes it possible to execute traffic in both
zones simultaneously (load sharing). It allows two disjunct databases that
have their "homes" on two different TelORB zones, with standby copies on the
other's home zone. Note that R13 will only support load sharing between two
zones.


Most of the directives below are valid for when the Scheduler is not being used.

All actions in this section are performed in Zone 1.

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions Action Values 1. Load Zone 1 2. Add remote zone 2 3. Add remote host/port Host: 134.138.xx.101 Port: 5666 (Mark zone 2 first) Host: 134.138.xx.102 Port: 5666 Host: 134.138.yy.101 Port: 5666 Host: 134.138.yy.102 Port: 5666 4. Activate links 5. Add netshared DU suites TelORB netshared DU suites: 1001791 0 0 1 2 1001791 1 1 2 1 1001791 2 11 1 2 (default) Demo2000 application netshared DU suites: 524308 0 999 1 2 10001 0 999 1 2 (to make OP4 traffic work) Demo application netshared DU suites: 524600 0 99 1 2 Java application netshared DU suites: 1001515 0 99 1 2 HLR application netshared DU suites: See separate section 6. Enable redundancy 7. Install replication map 8. Only for PNR: TakeOver 2 9. Only for PNR: Add siblings Demo2000 application netshared DU suites: 524308 10001 (to make OP4 traffic work) Demo application netshared DU suites: 524600 Java application netshared DU suites: 1001515 HLR application netshared DU suites: See section 10. Only for PNR: Install replication map 11. Create backup 12. Continue with zone 2 (PNR = Partitioned Network Redundancy)

   Prerequisites

   - Load the zone, if not already performed.
   - Start the TelORB Manager, with the netred option (if not already done),
     from one of the IO processors, i.e. use the parameter "-netred" when
     starting the TelORB Manager.
   - Set DNS values, if not already performed.
   - Create a backup (for fall-back reasons), if not already performed.
   - If traffic is executing in Zone 2, turn the traffic off.
   - It is possible to execute traffic in Zone 1 during initiation of network
     redundancy, but if partitioned network redundancy is to be initiated, it
     is best to turn the traffic off. Otherwise, the already created database
     objects will not be partitioned (they will stay as 1,2). 

   Specify remote zone data and activate network redundancy links

   - Verify that the zone identity is "... Zone : 1" on any of the NetRed cards
     in the TelORB Manager.

   - Select "Add Remote Zone" from the NetRed Control card.

   - In the opened window, fill in the zone number of the remote zone, i.e. "2"
     and click "OK".

   - Mark the remote zone number below the heading "Remote Zones" on the NetRed
     Control card.

   - Check that the link status is "Link to Zone 2 : Inactive" on the NetRed
     Control card.

   - Check that the network redundancy status is "Status : Disabled" on the
     NetRed Config card.

   - Start initiating the first IP address of the remote zone by clicking the
     button "Add Host/Port" on the NetRed Control card.
     In the opened window, in the "Host" input field, fill in the IP address of
     the first TelORB processor in the remote zone over ethernet switch A which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field.
     See example below.
   - Click "OK" to add the IP address and port number.

   - Start initiating the second IP address of the remote zone by clicking the
     button "Add Host/Port".
     In the opened window, in the "Host" input field, fill in the IP address of
     the second TelORB processor in the remote zone over ethernet switch A which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field.
     See example below.
   - Click "OK" to add the IP address and port number.

   - Start initiating the third IP address of the remote zone by clicking the
     button "Add Host/Port".
     In the opened window, in the "Host" input field, fill in the IP address of
     the first TelORB processor in the remote zone over ethernet switch B which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field. See example
     below.
   - Click "OK" to add the IP address and port number.

   - Start initiating the fourth IP address of the remote zone by clicking the
     button "Add Host/Port".
     In the opened window, in the "Host" input field, fill in the IP address of
     the second TelORB processor in the remote zone over ethernet switch B which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field.
     See example below.
   - Click "OK" to add the IP address and port number.

       An example of the entered IP addresses and ports for the remote zone to7:
          Host: 134.138.67.101    Port: 5666
          Host: 134.138.67.102    Port: 5666
          Host: 134.138.68.101    Port: 5666
          Host: 134.138.68.102    Port: 5666

   - Activate the network redundancy links by clicking "Activate Link" on the
     NetRed Control card.

   - Check that the link status is "Link to Zone 2 : Active" on the NetRed
     Control card.

   Configure netshared DU suites and enable network redundancy

   - Set the following TelORB DU suites as being netshared by clicking the "Add"
     button below the heading "Netshared DU Suites" on the NetRed Config card:

       Class Id:    1001791
       Low DU:      0
       High DU:     0
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify (shows 0-11).

     Click "Add".
       Class Id:    1001791
       Low DU:      1
       High DU:     1
       Owner Zone:  2
       Backup Zone: 1
     Click "OK".
     Click the "Refresh" button to verify (shows 0-0, 1-1 and 2-11).

     Click "Add". (Not necessary, since this DU suite is automatically configured.)
       Class Id:    1001791
       Low DU:      2
       High DU:     11
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify (shows 0-0, 1-1 and 2-11).

   - Only applicable if the Demo application is to be used:
     Set the following Demo application DU suites as being netshared by clicking
     the "Add" button below the heading "Netshared DU Suites" on the NetRed
     Config card:

       Class Id:    524600
       Low DU:      0
       High DU:     99
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify.

   - Only applicable if the Java application is to be used:
     Set the following Java application DU suites as being netshared by clicking
     the "Add" button below the heading "Netshared DU Suites" on the NetRed
     Config card:

       Class Id:    1001515
       Low DU:      0
       High DU:     99
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify.

   - Only applicable if the Demo2000 application is to be used:
     Set the following Demo2000 application DU suites as being netshared by
     clicking the "Add" button below the heading "Netshared DU Suites" on the
     NetRed Config card:
       Class Id:    524308
       Low DU:      0
       High DU:     999
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify.

     and also the following to make OP4 traffic to be successfully executed:
       Class Id:    10001
       Low DU:      0
       High DU:     999
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify.

   - Only applicable if the HLR application is to be used:
     To get the HLR application DU suites set as netshared, either use the
     CAT tool or run the following script from IO processor 1
     at /opt/Scheduler/etc/:
       ./AddDuSuite.ksh ../config/Jam2_0_pots.config
     (The data about which DU suites that should be set as netshared is
     specified in the file /opt/Scheduler/config/Jam2_0_pots.config.)
     
   - Enable network redundancy by clicking the "Enable" button on the NetRed
     Config card.

   - Check that the network redundancy status is "Status : Enabled" on the
     NetRed Config card.

   Install replication map

   - Install the replication map by clicking the "Install Replication Map"
     button on the NetRed Config card.
     This will store information about which DUs that are netshared in the
     `database cache' for faster access to this information (instead of
     accessing the database every time this information is required).
     (The Class IDs (classNo) and DU information will appear in the console
     for TelORB processor 1 or 2. Verify that this information is equivalent
     with what was previously entered.)

   Configure partitioned network redundancy (siblings), if desired (includes
   install replication map)

   - Check the mode of Zone 1 relative to Zone 2, by clicking the "Relative
     Mode" button on the NetRed Control card and, in the opened window, filling
     in "2" (Zone 2) and then clicking "OK".
     The mode should be "Netshared". (This mode does not yet say anything about
     the real zone mode, it is just a default value during the initiation of
     network redundancy.)

   - Bring up the "Network Redundancy Traffic Control" window, by selecting it
     below "Loadable Extras" on the Home card in the TelORB Manager.

   - Set the zone in TakeOver mode: In the "Network Redundancy Traffic Control"
     window, click the "Takeover" button, and in the opened window, fill in "2"
     (Zone 2) and then click "OK".
     (To be able to add siblings, the zone mode must be "TakeOver".)

   - Verify the mode of Zone 1 relative to Zone 2, by clicking the "Relative
     Mode" button on the NetRed Control card and, in the opened window, filling
     in "2" (Zone 2) and then clicking "OK".
     The mode should be "TakeOver".

   - Below the heading "Netshared Siblings" on the NetRed Config card, click
     the "Add" button.

   - In the opened window, fill in the class id (number) of a POT that should
     be partitioned netshared, e.g.
       For the Demo application:      524600
       For the Java application:      1001515
       For the Demo2000 application:  524308, 10001
       For the HLR application:       536993, 531462, 531250, 531463, 530020,
                                      530024, 530022, 530028, 534282, 534284,
                                      534280, 530513, 530195, 530456, 530173, 
                                      527799, 527801, 536070, 530026, 527807, 
                                      537201, 527803, 524713, 524717, 530552,
                                      524715, 527805, 530030, 527809, 536004, 
                                      535275, 524879, 530032, 533560, 530163, 
                                      524797, 524683  (//537861 //533575)

     Click the "OK" button after specification of each POT.
     If the operation fails you'll get an exception.
     Repeat the procedure for all POTs that should be partitioned netshared.
     Click the "Refresh" button to verify.

   - Install the replication map by clicking the "Install Replication Map"
     button on the NetRed Config card.

   Verify status and create backup

   - Verify the mode of Zone 1 relative to Zone 2, by clicking the "Relative
     Mode" button on the NetRed Control card and, in the opened window, filling
     in "2" (Zone 2) and then clicking "OK".
     If partitioned network redundancy is configured, the mode should be
     "TakeOver", otherwise "Netshared".
     However, if the remote zone is not up and running, the mode should be
     "TakeOver" in any case (not verified yet).

   - Verify that the network redundancy status is "Status : Enabled" on the
     NetRed Config card.

   - Create a backup.

All actions in this section are performed in Zone 2, unless otherwise specified.

Detailed instructions can be found below the section for Shortcut instructions.

Shortcut instructions Action Values 1. Load Zone 2 2. Add remote zone 1 3. Add remote host/port Host: 134.138.xx.101 Port: 5666 (Mark zone 1 first) Host: 134.138.xx.102 Port: 5666 Host: 134.138.yy.101 Port: 5666 Host: 134.138.yy.102 Port: 5666 4. Activate links 5. Add netshared DU suites TelORB netshared DU suites: 1001791 0 0 1 2 1001791 1 1 2 1 1001791 2 11 1 2 (default) (If traffic has been executing in Zone 2 and netshared DU suites that have previously been added for Zone 1 have been accessed in Zone 2, these netshared DU suites have to be added in Zone 2 too. If they are not added, the external sync will fail.) 6. Enable redundancy 7. Install replication map 8. Start reconciliation 1 (In TelORB R14, steps 9-12 will be done automatically?) 9. If zone 1 is executing traffic, create backup in zone 1 10. Copy backup from Zone 1 to Zone 2 11. Start external sync 1 & Backup path + /databaseBackup (automatically generates backup) 12. In zone 1: GiveBack to Zone 2 2 13. Install replication map 14. Create backup (In TelORB R14, it may be necessary to perform a remote sync (or external sync) to bring the zones up in Netshared mode. TR UABtr04939 issued for this error.)

   Prerequisites

   - Load the zone, if not already performed.
   - Start the TelORB Manager, with the netred option (if not already done),
     from one of the IO processors, i.e. use the parameter "-netred" when
     starting the TelORB Manager.
   - Set DNS values, if not already performed.
   - If traffic is executing in Zone 2, turn the traffic off.
   - Create a backup (for fall-back reasons), if not already performed.

   Specify remote zone data and activate network redundancy links

   - Verify that the zone identity is "... Zone : 2" on any of the NetRed cards
     in the TelORB Manager.

   - Select "Add Remote Zone" from the NetRed Control card.

   - In the opened window, fill in the zone number of the remote zone, i.e. "1"
     and click "OK".

   - Mark the remote zone number below the heading "Remote Zones" on the NetRed
     Control card.

   - Check that the link status is "Link to Zone 1 : Inactive" on the NetRed
     Control card.

   - Check that the network redundancy status is "Status : Disabled" on the
     NetRed Config card.

   - Start initiating the first IP address of the remote zone by clicking the
     button "Add Host/Port" on the NetRed Control card.
     In the opened window, in the "Host" input field, fill in the IP address of
     the first TelORB processor in the remote zone over ethernet switch A which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field.
     See example below.
   - Click "OK" to add the IP address and port number.

   - Start initiating the second IP address of the remote zone by clicking the
     button "Add Host/Port".
     In the opened window, in the "Host" input field, fill in the IP address of
     the second TelORB processor in the remote zone over ethernet switch A which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field.
     See example below.
   - Click "OK" to add the IP address and port number.

   - Start initiating the third IP address of the remote zone by clicking the
     button "Add Host/Port".
     In the opened window, in the "Host" input field, fill in the IP address of
     the first TelORB processor in the remote zone over ethernet switch B which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field. See example
     below.
   - Click "OK" to add the IP address and port number.

   - Start initiating the fourth IP address of the remote zone by clicking the
     button "Add Host/Port".
     In the opened window, in the "Host" input field, fill in the IP address of
     the second TelORB processor in the remote zone over ethernet switch B which
     has the pool DicosNetRedConnectPool allocated to it.     
     Then fill in the port number 5666 in the "Port" input field.
     See example below.
   - Click "OK" to add the IP address and port number.

       An example of the entered IP addresses and ports for the remote zone to8:
          Host: 134.138.81.101    Port: 5666
          Host: 134.138.81.102    Port: 5666
          Host: 134.138.82.101    Port: 5666
          Host: 134.138.82.102    Port: 5666

   - Activate the network redundancy links by clicking "Activate Link" on the
     NetRed Control card.

   - Check that the link status is "Link to Zone 1 : Active" on the NetRed
     Control card.

   Configure netshared DU suites and enable network redundancy

   - Set the following TelORB DU suites as being netshared by clicking the "Add"
     button below the heading "Netshared DU Suites" on the NetRed Config card:

       Class Id:    1001791
       Low DU:      0
       High DU:     0
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify (shows 0-11).

     Click "Add".
       Class Id:    1001791
       Low DU:      1
       High DU:     1
       Owner Zone:  2
       Backup Zone: 1
     Click "OK".
     Click the "Refresh" button to verify (shows 0-0, 1-1 and 2-11).

     Click "Add". (Not necessary, since this DU suite is automatically configured.)
       Class Id:    1001791
       Low DU:      2
       High DU:     11
       Owner Zone:  1
       Backup Zone: 2
     Click "OK".
     Click the "Refresh" button to verify (shows 0-0, 1-1 and 2-11).

   - If traffic has been executing in Zone 2 and netshared DU suites that have
     previously been added for Zone 1 have been accessed in Zone 2, these
     netshared DU suites have to be added in Zone 2 too.
     If they are not added, the external sync will fail. (This might be an
     error and is not verified yet.)

   - Enable network redundancy by clicking the "Enable" button on the NetRed
     Config card.

   - Check that the network redundancy status is "Status : Enabled" on the
     NetRed Config card.

   Install replication map

   - Install the replication map by clicking the "Install Replication Map"
     button on the NetRed Config card.
     (The Class IDs (classNo) and DU information will appear in the console
     for TelORB processor 1 or 2. Verify that this information is equivalent
     with what was previously entered.)

   Start reconciliation

   - Start reconciliation by clicking the "Start Reconciliation" button on the
     NetRed Control card.

   - In the opened window, fill in the zone number of the remote zone, i.e. "1"
     and then click "OK".
     Verify that the following printout in the console for TelORB processor 1
     or 2 is received:
     "-----> Waiting for external synch to start....."
     (If this printout is not received, the communication between the zones is
     most probably not established. Check e.g. that all cables between the zones
     and the router are connected. Also check that the router is fully
     functional.)

   Note for TelORB R14:
     The following will be done automatically when the "Start Reconciliation"
     button is clicked upon:
       o Creation of backup in Zone 1
       o Copying of backup from Zone 1 to Zone 2
       o External synchronisation in Zone 2
       o Creation of backup in Zone 2
     This means that these steps should be disregarded below.

     The following notifications will be received in TelORB R14 (not necessarily
     in order of appearance):
       o Notification in Zone 2: Reconciliation Started as Standby
       o Notification in Zone 1: Reconciliation Started as Primary
       o Notification in Zone 1: Backup Started
       o Notification in Zone 1: Transfer started
       o Notification in Zone 1: Backup Finished Successfully
       o Notification in Zone 1: Transfer finished
       o (Notification in Zone 1: Remove Backup Started)
       o Notification in Zone 2: External Sync Started
       o Notification in Zone 2: External Sync Succeeded
       o Notification in Zone 2: Backup Started
       o Notification in Zone 2: Backup Finished Successfully
       o Notification in Zone 2: Reconciliation Finished as Standby
       o Notification in Zone 1: Reconciliation Finished as Primary
       o (Notification in Zone 1: Remove Backup Finished Successfully)

   Verify status (Valid for TelORB R13)

   - Verify the mode of Zone 2 relative to Zone 1, by clicking the "Relative
     Mode" button on the NetRed Control card and, in the opened window, filling
     in "1" (Zone 1) and then clicking "OK".
     The mode should be "Down".

   - Verify that the network redundancy status is "Status : Enabled" on the
     NetRed Config card.

   - The zones should now have the following data:

       Zone 1 (Default primary)		     Zone 2 (Default standby)
       ------------------------		     ------------------------
       Mode:   TakeOver			     Mode:   Down
       State:  ServerReconcileFinished(10)   State:  ReadyToReconcileClient(5)
       Status: Enabled			     Status: Enabled   (Disabled in R14)

   Start external synchronisation

   - If Zone 1 is executing traffic, create a backup in Zone 1. This is not
     necessary, if Zone 1 is not executing traffic.
     If traffic is executing in Zone 1, the TelORB processor load viewer will
     show some yellow load in Zone 2 and the TelORB processor consoles in
     Zone 2 will show lots of queued transactions from Zone 1. This indicates
     that replication from Zone 1 to Zone 2 is in progress and also that Zone 2
     has a backlog which also results in the alarm "Out of sync" in Zone 2. (The
     alarm is valid from AD12.)

   - Copy the last created backup in Zone 1 to IO processor 1 in Zone 2 below
     e.g. directory /opt/telorb/axe/, by using ftp, or by using tos1/tos2, which
     is described in
     Copy a backup from primary zone to standby zone by using tos1/tos2.

     Note for TelORB R14:
       If the last created backup is not automatically copied to directory
       /opt/telorb/axe/loadingGroup01_1/reconciliation/ (or loadingGroup01_2),
       it must be copied manually.

   - To be able to start external sync, bring up the "Network Redundancy Traffic
     Control" window, by selecting it below "Loadable Extras" on the Home card
     in the TelORB Manager.

   - Start external sync by clicking the "Extern Sync" button in the "Network
     Redundancy Traffic Control" window and thereafter, in the opened window,
     filling in "1" (Zone 1) and the name of the copied backup plus the
     directory name "/databaseBackup" as follows:
       Zone Id:   1
       Backup path: <backup_name>/databaseBackup
     Then click "OK".

     Note for TelORB R14:
       Use the backup path
       loadingGroup01_1/reconciliation/<backup_name>/databaseBackup
       (or loadingGroup01_2).

   - Check that notification "External Sync Started" is received.

   - Wait until notification "External Sync Succeeded" is received.
     (The result printout: "-----> External synch finished successfully" is
     received in the console for TelORB processor 1 or 2.)

   - A backup will automatically be created in Zone 2. Wait for it to finish.

   - If traffic is executing in Zone 1, the alarm "Out of sync" in Zone 2 should
     be cleared.

   - The zones should now have the following data:

	Zone 1 (Default primary)	Zone 2 (Default standby)
	------------------------	------------------------
	Mode:   TakeOver		Mode:   Down
        State:  ReadyToGiveBack(11)	State:  ReadyToTakeBack(12)
 	Status: Enabled			Status: Enabled

   - If you want to check which DU suites that are set as netshared and which
     netshared siblings that exist, use the "Refresh" buttons below respective
     heading ("Netshared DU Suites" and "Netshared Siblings") on the NetRed
     Config card. (However, all netshared DU suites will be listed in the
                   console for TelORB processor 1 or 2 when performing the
                   installation of replication map below.)

   Perform the action "GiveBack to Zone 2"

   - Action to be taken in Zone 1: Perform a "GiveBack" to Zone 2 by clicking
     the "Give Back" button in the "Network Redundancy Traffic Control" window
     and thereafter, in the opened window, filling in "2" (Zone 2) and then
     clicking "OK".

   - The zones should now have the following data:

	Zone 1 (Default primary)	Zone 2 (Default standby)
	------------------------	------------------------
	Mode:   Netshared		Mode:   Netshared
        State:  Idle(0)			State:	Idle(0)
 	Status: Enabled			Status: Enabled

  Install replication map

   - Install the replication map by clicking the "Install Replication Map"
     button on the NetRed Config card (in Zone 2).

  Create a backup

   - Create a backup.

   - The zones should still have the following data:

	Zone 1 (Default primary)	Zone 2 (Default standby)
	------------------------	------------------------
	Mode:   Netshared		Mode:   Netshared
        State:  Idle(0)			State:	Idle(0)
 	Status: Enabled			Status: Enabled

   - The initiation of network redundancy is now completed.

   - Start traffic in Zone 1, if not already executing, and verify that
     replication to Zone 2 works by e.g. checking the load viewer.
     If partitioned network redundancy is initiated, it is also possible to
     start traffic in Zone 2. In this case, start traffic in Zone 2 and verify
     that replication to Zone 1 also works.

All actions in this section are performed in Zone 1.

   Prerequisites: Start the zone and create a backup
   - Load the zone, if not already performed.
   - Set DNS values, if not already performed.
   - Create a backup (for fall-back reasons), if not already performed.
   - If traffic is executing in Zone 2, turn the traffic off.
   - It is possible to execute traffic in Zone 1 during the initiation of
     network redundancy.

   Activate redundancy (Create the remote zone object)
   - Select "Add Remote Zone" in the TelORB Browser.
   - In the opened window, fill in zone id of the remote zone, i.e. "2" and
     click "OK"/"Apply".
   - Quit the opened window.

   - Mark the remote zone number below the heading "Remote Zones" in the TelORB
     Manager/Browser.

   - Select "Config Remote Zone".
     In the opened window, click "Get Status" which should show "Inactive".
     In the opened window, click "Is working?" which should show "No". (Valid
     from AD12.)

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the first TelORB processor over ethernet switch A in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it, in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the second TelORB processor over ethernet switch A in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it, in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the first TelORB processor over ethernet switch B in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it, in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the second TelORB processor over ethernet switch B in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it, in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

       An example of the entered IP addresses and ports for the remote zone to7:
          134.138.67.101 : 5666
          134.138.67.102 : 5666
          134.138.68.101 : 5666
          134.138.68.102 : 5666

   - In the opened window, click "Activate Link".

   - In the opened window, click "Get Status" which should show "Active".
   - In the opened window, click "Is working?" which should show "Yes". (Valid
     from AD12.)
   - Quit the opened window.

   Configure netshared DUs and enable redundancy
   - Select "Config Local Zone" in the TelORB Browser.

   - In the opened window, below the heading "Adding DU Suites", fill in the
     following for TelORB netshared DUs.
         Class Id:    1001791
         Low DU:      0
         High DU:     0
         Owner Zone:  1
         Backup Zone: 2
     Click "Add".

         Class Id:    1001791
         Low DU:      1
         High DU:     1
         Owner Zone:  2
         Backup Zone: 1
     Click "Add".

         Class Id:    1001791
         Low DU:      2
         High DU:     11
         Owner Zone:  1
         Backup Zone: 2
     Click "Add".

   - Only applicable if the Demo application is to be used:
     In the opened window, below the heading "Adding DU Suites", fill in the
     following to get the Demo application DU suites set as netshared.
         Class Id:    524600
         Low DU:      0
         High DU:     99
         Owner Zone:  1
         Backup Zone: 2
     Click "Add".

   - Only applicable if the Java application is to be used:
     In the opened window, below the heading "Adding DU Suites", fill in the
     following to get the Java application DU suites set as netshared.
         Class Id:    1001515
         Low DU:      0
         High DU:     99
         Owner Zone:  1
         Backup Zone: 2
     Click "Add".

   - Only applicable if the Demo2000 application is to be used:
     In the opened window, below the heading "Adding DU Suites", fill in the
     following to get the Demo2000 application DU suites set as netshared.
         Class Id:    524308
         Low DU:      0
         High DU:     999
         Owner Zone:  1
         Backup Zone: 2
     Click "Add".

   - Only applicable if the HLR application is to be used:
     Run the following script, to get the HLR application DU suites set as
     netshared, from IO processor 1 at /opt/Scheduler/etc/:
       ./AddDuSuite.ksh ../config/Jam2_0_pots.config
     (The data about which DU suites that should be set as netshared is
     specified in the file /opt/Scheduler/config/Jam2_0_pots.config.)

   - If you want to check which DU suites that are set as netshared, run the
     following script from IO processor 1 (or 2) at /opt/Scheduler/etc/:
       ./ListDuSuite.ksh  (Also see List DU suites (POTs.)
     If a list of all netshared DU suites is not obtained, try to enter the
     same command (./ListDuSuite.ksh) after "Install Replication Map" below.
     This information will also be obtained when installing the replication map
     below.
     
   - In the opened window, click "Enable".

   Install replication map and create a backup
   - In the opened window, click "Install Replication Map" to store information
     about which DUs that are netshared in the `database cache' for faster
     access to this information (instead of accessing the database every time
     this information is required).
     (The Class IDs (classNo) and DU information will appear in the console
     for TelORB processor 1 or 2. Verify that this information is equivalent
     with what was previously entered.)

   - In the opened window, click "My Zone Id" which should show "1" (Zone 1).
   - In the opened window, fill in the input field next to the button "Mode Rel
     Zone" with "2" (Zone 2) and then click "Mode Rel Zone". If the remote zone
     is up and running, the mode should be "Netshared". If the remote zone is
     not up and running, the mode should be "TakeOver" (not verified yet).
   - In the opened window, click "Zone Status" which should show "Enabled".
   - Keep the opened window (Edit Local Zone), to continuously be able to check
     the mode and status of Zone 1 during the installation of network
     redundancy.

   - Create a backup.

All actions in this section are performed in Zone 2, unless otherwise specified.

   Prerequisites: Start the zone and create a backup
   - Load the zone, if not already performed.
   - Set DNS values, if not already performed.
   - If traffic is executing in Zone 2, turn the traffic off.
   - Create a backup (for fall-back reasons), if not already performed.

   Activate redundancy (Create the remote zone object)
   - Select "Add Remote Zone" in the TelORB Browser.
   - In the opened window, fill in zone id of the remote zone, i.e. "1" and
     click "Apply".
   - Quit the opened window.

   - Mark the remote zone number below the heading "Remote Zones" in the TelORB
     Browser and select "Config Remote Zone".
   - In the opened window, click "Get Status" which should show "Inactive".
   - In the opened window, click "Is working?" which should show "No". (Valid
     from AD12.)

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the first TelORB processor over ethernet switch A in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the second TelORB processor over ethernet switch A in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the first TelORB processor over ethernet switch B in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

   - In the opened window, next to the button "Add(host/pt)", fill in the IP
     address of the second TelORB processor over ethernet switch B in the remote
     zone which has the pool DicosNetRedConnectPool allocated to it in the
     leftmost input field and then fill in the port number 5666 in the rightmost
     input field. See example below.
   - Click "Add (host/pt)" to add the IP address and port number.

       An example of the entered IP addresses and ports for the remote zone to8:
          134.138.81.101 : 5666
          134.138.81.102 : 5666
          134.138.82.101 : 5666
          134.138.82.102 : 5666

   - In the opened window, click "Activate Link".
   - In the opened window, click "Get Status" which should show "Active".
   - In the opened window, click "Is working?" which should show "Yes". (Valid
     from AD12.)
   - Quit the opened window.

   Configure netshared DUs and enable redundancy
   - Select "Config Local Zone" in the TelORB Browser.
   - In the opened window, below the heading "Adding DU Suites", fill in the
     following for TelORB netshared DUs.
         Class Id:    1001791
         Low DU:      0
         High DU:     0
         Owner Zone:  1
         Backup Zone: 2
     Click "Add".

         Class Id:    1001791
         Low DU:      1
         High DU:     1
         Owner Zone:  2
         Backup Zone: 1
     Click "Add".

         Class Id:    1001791
         Low DU:      2
         High DU:     11
         Owner Zone:  1
         Backup Zone: 2
     Click "Add".

   - If traffic has been executing in Zone 2 and some of the netshared DUs
     that have previously been added (Adding DU Suites) for Zone 1 have been
     accessed in Zone 2, these netshared DUs have to be added in Zone 2 too.
     If they are not added, the external sync will fail. (This might be an
     error.)

   - In the opened window, click "Enable".

   Install replication map
   - In the opened window, click "Install Replication Map".
     (The Class IDs (classNo) and DU information will appear in the console
     for TelORB processor 1 or 2. Verify that this information is equivalent
     with what was previously entered.)

   Start reconciliation (external sync)
   - In the opened window, in the input field next to the button "Start
     Reconciliation", fill in zone id of the remote zone, i.e. "1" and then
     click "Start Reconciliation".
     Check that the following printout in the console for TelORB processor 1
     or 2 is received:
     "-----> Waiting for external synch to start....."
     (If this printout is not received, the communication between the zones is
     most probably not established. Check e.g. that all cables are connected
     between the zones and the router in between. Also check that the router
     is fully functional.)

   - In the opened window, click "My Zone Id" which should show "2" (Zone 2).
   - In the opened window, fill in the input field next to the button "Mode Rel
     Zone" with "1" (Zone 1) and then click "Mode Rel Zone". This should show
    "Down".
   - In the opened window, click "Zone Status" which should show "Enabled"
     (may show "Disabled" in AD9.05.3).
   - Keep the opened window (Edit Local Zone), to continuously be able to check
     the mode and status of Zone 2 during the installation of network
     redundancy.


   - The zones should now have the following data:

       Zone 1 (Default primary)		     Zone 2 (Default standby)
       ------------------------		     ------------------------
       Mode:   TakeOver			     Mode:   Down
       State:  ServerReconcileFinished(10)   State:  ReadyToReconcileClient(5)
       Status: Enabled			     Status: Enabled
						     ("Disabled" in AD9.05.3)

   - If Zone 1 is executing traffic, create a backup in Zone 1. This is not
     necessary, if Zone 1 is not executing traffic.
     If traffic is executing in Zone 1, the TelORB processor load viewer will
     show some yellow load in Zone 2 and the TelORB processor consoles in
     Zone 2 will show lots of queued transactions from Zone 1. This indicates
     that replication from Zone 1 to Zone 2 is in progress and also that Zone 2
     has a backlog which also results in the alarm "Out of sync" in Zone 2. (The
     alarm is valid from AD12.)

   - Copy the last created backup in Zone 1 (to8) to e.g. directory
     /opt/telorb/axe/ on IO1 in Zone 2 (to7), by using tos1/tos2 (it is, of
     course, also possible to use ftp)(use valid TelORB system names, i.e.
     adjust to7 and to8 below):
       Either, when standing on /to8/to8io1/telorb/axe/loadingGroup01_1/backups/
         cp -r _backup_name_/ /to7/to7io1/telorb/axe/
       or when standing on /to7/to7io1/telorb/axe/
         cp -r /to8/to8io1/telorb/axe/loadingGroup01_1/backups/_backup_name_/ .
     (Actually, the backup should be copied to directory
     /opt/telorb/axe/loadingGroup01_1/reconciliation/
     on IO processor 1 as is the case for the customer sites, but this is not
     done for convenience reasons.)

   - Select "Manage Traffic" in the TelORB Browser (in Zone 2).
   - In the opened window, below the heading "External Syncing", fill in the
     remote zone ID, and the copied backup name plus the directory name
     "/databaseBackup" as follows:
       Zone Id:   1
       Backup path: _backup_name_/databaseBackup
     Click "Perform Sync" which will cause an external sync to start.
   - Check that notification type 39 (External sync started) is received. (Valid
     from AD12.)
   - Wait until notification type 40 (External sync succeeded) is received.
     (Valid from AD12.)
     (The result printout: "-----> External synch finished successfully" is
     received in the console for TelORB processor 1 or 2.)
   - A backup will automatically be created in Zone 2. Wait for it to finish.
   - If traffic is executing in Zone 1, the alarm "Out of sync" in Zone 2 should
     be cleared. (Valid from AD12.)
   - Quit the opened window.

   - If you want to check which DU suites that are set as netshared, run the
     following script from IO processor 1 (or 2) at /opt/Scheduler/etc/:
       ./ListDuSuite.ksh  (Also see List DU suites (POTs.)
     However, all netshared DU suites will be listed in the console for
     TelORB processor 1 or 2 when performing the installation of replication
     map in the step below.

   - The zones should now have the following data:

	Zone 1 (Default primary)	Zone 2 (Default standby)
	------------------------	------------------------
	Mode:   TakeOver		Mode:   Down
        State:  ReadyToGiveBack(11)	State:  ReadyToTakeBack(12)
 	Status: Enabled			Status: Enabled

   - Select "Manage Traffic" in the TelORB Browser in Zone 1.
   - In the opened window, in the input field next to the button "Give back to",
     fill in zone id of the remote zone, i.e. "2" and then click "Give back to".
   - Quit the opened window.

   - The zones should now have the following data:

	Zone 1 (Default primary)	Zone 2 (Default standby)
	------------------------	------------------------
	Mode:   Netshared		Mode:   Netshared
        State:  Idle(0)			State:	Idle(0)
 	Status: Enabled			Status: Enabled

  Install replication map, and create a backup or start a remote synchronization
   - In the kept window "Edit Local Zone", click "Install Replication Map" for
     Zone 2.

   - For ADs earlier than AD12: Create a backup in Zone 2. Wait for the backup
     to finish.

   - From AD12 and higher: Start remote sync in Zone 1 as follows.
       - Select "Manage Traffic" in the TelORB Browser in Zone 1.
       - In the opened window, click "Start Remote Sync".
       - Quit the opened window.
       - Wait for the following notifications in Zone 1:
           "Remote Sync Started"
           "Backup Started"
           "Backup Succeeded"
           "Remote Sync Succeeded" (If the notification "Remote Sync Requires
                                    External Sync" is received, an external sync
                                    is required, see Remote Sync: External sync.)
       - A backup will be created in Zone 2.

   - The zones should still have the following data:

	Zone 1 (Default primary)	Zone 2 (Default standby)
	------------------------	------------------------
	Mode:   Netshared		Mode:   Netshared
        State:  Idle(0)			State:	Idle(0)
 	Status: Enabled			Status: Enabled

   - Quit the kept windows "Edit Local Zone" for both zones, if desired.
   - Start traffic in Zone 1, if not already executing, and verify that
     replication to Zone 2 works by e.g. checking the load viewer.
   - The initiation of network redundancy is now completed.

Partitioned network redundancy makes it possible to execute traffic in both
zones simultaneously (load sharing). It allows two disjunct databases that
have their "homes" on two different TelORB zones, with standby copies on the
other's home zone. Note that R13 will only support load sharing between two
zones.

Use the TelORB Manager, or the Telorb Browser with at least the version 5.4.

1. Initiate network redundancy in Zone 1 and 2 as described in previous
   sections. It is important that you have performed "Install Replication
   Map" in both zones.

2. Get Zone 1 in TakeOver mode by preferably performing a Smooth TakeOver in
   Zone 1.

3. Perform the following in Zone 1:
     - Below the heading "Netshared Siblings", click on the "Add" button in the
       TelORB Manager.
     - In the opened window, fill in the class id (number) of a POT that should
       be partitioned netshared, e.g.
         For the Demo application:      524600
         For the Java application:      1001515
         For the Demo2000 application:  524308
         For the HLR application:       536993, 531462, 531250, 531463, 530020,
                                        530024, 530022, 530028, 534282, 534284,
                                        534280, 530513, 530195, 530456, 530173, 
                                        527799, 527801, 536070, 530026, 527807, 
                                        537201, 527803, 524713, 524717, 530552,
                                        524715, 527805, 530030, 527809, 536004, 
                                        535275, 524879, 530032, 533560, 530163, 
                                        524797, 524683  (//537861 //533575)
       - Click the "OK" button after specification of each POT. Repeat procedure
         for all POTs that should be partitioned netshared.
         If the operation fails you'll get an exception.
         The sibling information is updated in both zones.

     (Instructions on how to perform step 3 when using the Telorb Browser:
       - Click on the button "Config Local Zone".
       - In the input field "Class Id" for "Adding DU Suites":
         Fill in class number for a POT that should be partitioned netshared.
         The other input fields such as "Low DU" may be left empty.
       - Click on the button "Add Siblings". If the operation fails you'll get
         an exception.)

4. In Zone 1: Install the replication map by clicking the "Install Replication
              Map" button on the NetRed Config card.

5. In Zone 2: Order a reconciliation by clicking the button "Start
   Reconciliation".
   Check that the following printout is received in the TelORB processor console
   for TelORB processor 1 or 2:
     "Waiting for external synch to start....."
   NOTE: Just remote (periodic) sync is NOT enough! A full reconciliation
         is necessary!

6. In Zone 1: Create a backup.

7. Copy the backup from Zone 1 to Zone 2.

8. In Zone 2: Start external sync from the copied backup.
   (A backup will be created.)

9. In Zone 2: After the external sync and backup is finished, click the button
   "Install Replication Map".

10. In Zone 1: Perform a GiveBack.

11. Done.

Enter the following URL in the WWW browser:
http://134.138.xx.101:5557/DBN/Classes/DnrcZone_POT/1026056192-1  (Adjust xx to
                                                          valid network address)
                                                    (Enter any TelORB processor)

  Possible states in TelORB AD9.05.3 and TelORB AD11.4.1:

     0  Idle
     1  TakingOver
     2  EarlyNeg                (Check connection with other zone)
     3  TakeoverDuringEarlyNeg
     4  PrepareClientReconcile
     5  ReadyToReconcileClient
     6  ReconcilingClient
     7  BacklogProgressEnd
     8  Backup_ReadyToTakeBack
     9  ServerReconcile
    10  ServerReconcileFinished    
    11  ReadyToGiveBack
    12  ReadyToTakeBack
    13  RecClient_ReadyToTakeBack
    14  RecClient_Idle
    15  Backup_Idle
    16  TakeoverDuringRecClient
    17  GivingBack
    18  TakingBack
    19  GoingShared
    20  GoingDown
    21  NumberOfStates

  Possible states in TelORB AD12:

     0  Idle
     1  TakingOver
     2  EarlyNeg                (Check connection with other zone)
     3  TakeoverDuringEarlyNeg
     4  PrepareClientReconcile
     5  ReadyToReconcileClient
     6  ReconcilingClient
     7  BacklogProgressEnd
     8  Backup_ReadyToTakeBack
     9  ServerReconcile
    10  ServerReconcileFinished    
    11  ReadyToGiveBack
    12  ReadyToTakeBack
    13  RecClient_ReadyToTakeBack
    14  RecClient_Idle
    15  Backup_Idle
    16  TakeoverDuringActivity
    17  GivingBack
    18  TakingBack
    19  GoingShared
    20  GoingDown
    21  Disengaging_Idle
    22  Disengaging_ReadyToTakeBack
    23  Disengaging_ReadyToGiveBack
    24  Disengaging_ServerRec
    25  TakingOverSmooth
    26  GoingDownSmooth
    27  SynchingRemote_Idle
    28  SynchingRemote_ReadyToGiveBack
    29  NumberOfStates

  Possible states in TelORB R13 and TelORB R14 (fetched info from tbAD13p10 and
  tbAD14.8):

     0  Idle
     1  TakingOver
     2  EarlyNeg                (Check connection with other zone)
     3  TakeoverDuringEarlyNeg
     4  PrepareClientReconcile
     5  ReadyToReconcileClient
     6  ReconcilingClient
     7  BacklogProgressEnd
     8  Backup_ReadyToTakeBack
     9  ServerReconcile
    10  ServerReconcileFinished    
    11  ReadyToGiveBack
    12  ReadyToTakeBack
    13  RecClient_ReadyToTakeBack
    14  RecClient_Idle
    15  Backup_Idle
    16  TakeoverDuringActivity
    17  GivingBack
    18  TakingBack
    19  GoingShared
    20  GoingDown
    21  Disengaging_Idle
    22  Disengaging_ReadyToTakeBack
    23  Disengaging_ReadyToGiveBack
    24  Disengaging_ServerRec
    25  TakingOverSmooth
    26  GoingDownSmooth
    27  SynchingRemote_Idle
    28  SynchingRemote_ReadyToGiveBack
    29  GoDownDuringActivity
    30  NumberOfStates


Hints:
The network redundancy state values above can be fetched from the file
DnrcController.hh (enum ZoneState), located at e.g.
/ipims_dicos/ipims_dicos20/BS2/tbAD12/DICOS_SA/Database_SE/NetRed_OB/NetRedControl_OU/src/DnrcController.hh
(or enter "difind DnrcController" in the testbed build environment)

Use the TelORB Browser as follows.
  TelORB Browser:
    - Select "Config Local Zone" in the TelORB Browser.
    - In the opened window, click "My Zone Id" which should show own Zone ID,
      e.g. 1 or 2.
    - In the opened window, in the input field next to the button "Mode Rel
      Zone", fill in zone id of the remote zone, e.g. 1 or 2, and then click
      "Mode Rel Zone". This should show "TakeOver".
    - Bonus: In the opened window, click "Zone Status" which should show
      "Enabled".
    - Quit the opened window.


Possible modes:
  Netshared
  TakeOver
  Down

  Mode of zone   Update rights
  ------------   -------------
  Netshared      Can update objects that the zone owns
  TakeOver       Can update all objects
  Down           Cannot update any objects

  Today (1999), only one zone at a time have updating rights when both zones are
  in netshared mode. When the function `loadsharing between netshared zones' is
  implemented, the updating rights may be splitted between the zones, e.g.
  Zone 1 may own objects 0-49 and Zone 2 may own objects 50-99.

telnet 134.138.xx.101 8000                  (Log in to e.g. TelORB processor 1)
                                            (Adjust xx to valid network address)
$ /> cd NetRed

$ /NetRed> ls
NRC NRC

$ /NetRed> cat NRC

If tos1/tos2 is not available, use ftp to copy the backup.
In the examples below, the primary zone is toX and the standby zone is toY. Be
sure to substitute these names.

   Either when standing on /toX/toXio1/telorb/axe/loadingGroup01_1/backups/
      cp -r _backup_name_/ /toY/toYio1/telorb/axe/

   or

   when standing on /toY/toYio1/telorb/axe/
      cp -r /toX/toXio1/telorb/axe/loadingGroup01_1/backups/_backup_name_/ .

Note for TelORB R14: The last created backup should be copied to directory
     /opt/telorb/axe/loadingGroup01_1/.

Note: For convenience reasons, the axe directory is used, but at a customer
      site, the ../axe/loadingGroup01_1/reconciliation/ directory is used.

Do the following from where the TelORB processor console for the standby zone
are located, e.g. from to7/consolelogs/:
  /usr/xpg4/bin/egrep -e KeyToDU -e UTC log1

If a link has been broken (e.g. a transaction from the primary zone to the
standby zone has failed), the printout may look as follows:
          UTC time:    1999-10-18 12:34:51.871
          UTC time:    1999-10-18 12:49:51.896
  DEBUG INFO: KeyToDU returns 0 for 1994 (134.138.82.110 & 134.138.81.110)
  DEBUG INFO: KeyToDU returns 0 for 1994 (134.138.82.110 & 134.138.81.110)
          UTC time:    1999-10-18 13:04:51.924
          UTC time:    1999-10-18 13:19:51.991

This means that a dip has occurred sometime between 12:49:51 and 13:04:51.

If the number of TelORB processors are equal in both zones, most often the
TelORB processor that is pointed out is the correct one.

Check the log file in the primary zone which corresponds to the TelORB
processor that is pointed out, i.e. TelORB processor 10.
The log file may look as follows:

  ---- Network Redundancy link shut down ...
  DEBUG INFO: DdbnrPpClient: ConnectionLost/Timeout ... retrying

This section has not yet been verified.

Use the BackupFormatter from the distribution.

Stop demo application traffic.
Create a backup in each zone.

Use the scripts buForm and buDiff that are located on e.g. to3io2 at
/opt/telorb/tools/bin


Old:
Perform the following for Zone 1:
  telnet toXio1                   (Log in to IO processor 1 or 2. Adjust toX
                                   to valid TelORB system or use IP address)
  login: telorb                   (Type user name)
  Password:                       (Type password)
  cd /opt/telorb/axe/loadingGroup01_1/backups/
  cd _backup_name_/databaseBackup/
  tar cf backupZone1.tar *
  Repeat for Zone 2.

Perform the following on your local WS:
cd /home/telorb/                (The file "epws" should exist in directory)

source /ipims_dicos/ipims_dicos20/BS2/dicostb39/IP_CONF_INFO/EnvSettings
                                (Should get something like:
                                 EP_CONFIGPATH=/ipims_dicos/BS2/dicostb39/conf
                                 EP_SYSTEMROOT=/ipims_dicos/BS2/dicostb39
                                 EP_BUILDFLAGS=-O -DDDB_DEBUG
                                 EP_ROOT=/ipims_dicos/BS2/eptools5
setenv EP_WORKSPACE=/home/telorb/epws
(which DataFormatter)
which BackupFormatter           (Should get:
                                 /ipims_dicos/BS2/dicostb39/bin/BackupFormatter)


mkdir uabxxx                    (Create a directory for temporary use)
cd uabxxx
mkdir zone1
mkdir zone2
cd zone1
ftp toXio1                      (Use IO processor for Zone 1 to fetch backup
                                 from) (Adjust toX to valid TelORB system)
bin
cd /opt/telorb/axe/loadingGroup01_1/backups/_backup_name_/databaseBackup/
get backupZone1.tar
bye
cd ../zone2
ftp to6io1                      (Use IO processor for Zone 2 to fetch backup
                                 from)
bin
cd /opt/telorb/axe/loadingGroup01_1/backups/_backup_name_/databaseBackup/
get backupZone2.tar
bye

tar xf backupZone2.tar
cd ../zone1
tar xf backupZone1.tar
BackupFormatter -o -s -f lm.524600.* > formattedZone1  (Results e.g. in
                                                 pwd: /home/telorb/uabxxx/zone1
                                                 Exit 1)
cd ../zone2
BackupFormatter -o -s -f lm.524600.* > formattedZone2  (Results e.g. in
                                                 pwd: /home/telorb/uabxxx/zone2
                                                 Exit 1)
diff formattedZone2 ../zone1/formattedZone1 > diffResult

The size of diffResult should be 0 (zero). If not:
more diffResult | grep DeAppPOT


Old:
Perform the following for each zone:
  telnet toXio1                   (Log in to IO processor 1 or 2. Adjust toX
                                   to valid TelORB system or use IP address)
  login: telorb                   (Type user name)
  Password:                       (Type password)
  cd /opt/telorb/axe/loadingGroup01_1/backups/_backup_name_/databaseBackup/
  BackupFormatter -o -s -f lm.524600.* > _file1_  (LM for demo application)
                                                  (Creates _file1_ with one
                                                   line per record)
  sort _file1_ > _file2_zone1_
  Repeat for other zone.

diff _file2_zone1_ _file2_zone2_ > diffresult

grep -v DdbnrMdp diffresult       (No long strings should appear. Strings like
                                   "3002c3002" are acceptable)

Hints:
BackupFormatter -h                (Get BackupFormatter help)
grep Synched log3

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
					A: Zone reload
M: Netshared S: Idle(0) U: Enabled	M: - S: - U: -
L: Network Redundancy link shut down ...

The Scheduler should perform an immediate TakeOver in Zone 1. If the Scheduler
is not used, the TakeOver in Zone 1 is automatically performed after the zone
reload is finished.

M: TakeOver S: ServerReconcile-		M: Down S: ReadyToReconcileClient(5)
   Finished(10)	U: Enabled		   U: Enabled
					L: Waiting for external synch to
					   start.....
					At this point, all netshared database
					objects have been cleared in Zone 2,
					e.g. no subscriber data exists in zone
					2.
					AL: Out of sync (backlog) (If traffic is
					    executing)
A: Create backup
   (This is automatically done in TelORB R14)
   (Do not start remote sync)
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
					N: External Sync Started
					N: External Sync Succeeded
					N: Backup Started
					N: Backup Succeeded
					AL: Out of sync cleared (no backlog)
M: TakeOver S: ReadyToGiveBack(11)	M: Down S:ReadyToTakeBack(12)
   U:Enabled				   U: Enabled
A: GiveBack
   (This is automatically done in TelORB R14)
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Zone reload
M: - S: - U: -				M: Netshared S: Idle(0) U: Enabled
					L: Network Redundancy link shut down ...

The Scheduler orders Zone 2 to perform an immediate TakeOver. If the Scheduler
is not used, the TakeOver in Zone 2 is automatically performed after the zone
reload is finished.

M: Down S: ReadyToReconcileClient(5)	M: TakeOver S: ServerReconcile-
   U: Disabled				   Finished(10)	U: Enabled
L: Waiting for external synch to
   start.....
					A: Create backup
					A: Copy backup to Zone 1
A: Perform ext sync (+ aut backup)


M: Down S: ReadyToTakeBack(12)		M: TakeOver S: ReadyToGiveBack(11)
   U: Enabled				   U: Enabled
					A: GiveBack
M: TakeOver S: Idle(0) U: Enabled	M: Down S: Idle(0) U: Enabled
					A: Start reconciliation
M: TakeOver S: ServerReconcile-		M: Down S: ReadyToReconcileClient(5)
   Finished(10)	U: Enabled		   U: Enabled
					L: Waiting for external synch to
					   start.....
A: Create backup
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
M: TakeOver S: ReadyToGiveBack(11)	M: Down S:ReadyToTakeBack(12)
   U:Enabled				   U: Enabled
A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Zone reload
M: - S: - U: -				M: Netshared S: Idle(0) U: Enabled
					L: Network Redundancy link shut down ...

The Scheduler orders Zone 2 to perform an immediate TakeOver. If the Scheduler
is not used, the TakeOver in Zone 2 is automatically performed after the zone
reload is finished.

M: Down S: ReadyToReconcileClient(5)	M: TakeOver S: ServerReconcile-
   U: Enabled				   Finished(10)	U: Enabled
L: Waiting for external synch to
   start.....
AL: Out of sync (backlog) (If traffic
    is executing)
					A: Create backup
                                           (This is automatically done in TelORB
                                            R14)
					   (Do not start remote sync)
					A: Copy backup to Zone 1
A: Perform ext sync (+ aut backup)
N: External Sync Started
N: External Sync Succeeded
N: Backup Started
N: Backup Succeeded
AL: Out of sync cleared (no backlog)
M: Down S: ReadyToTakeBack(12)		M: TakeOver S: ReadyToGiveBack(11)
   U: Enabled				   U: Enabled
					A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Zone reload				A: Zone reload
M: - S: - U: -				M: - S: - U: -
M: Down S: Idle(0) U: Enabled		M: Down S: Idle(0) U: Enabled
Al: Reconciliation Needed		Al: Reconciliation Needed

(Traffic will not be replicated, since both zones are in down mode. Not possible
 for traffic to be executed.)

A: TakeOver
Al: Reconciliation Needed cleared
M: TakeOver S: Idle(0) U: Enabled	M: Down S: Idle(0) U: Enabled

(Traffic will be replicated, but the replications will just be discarded.
 Possible for traffic to be executed in Zone 1 only.)

					L: DEBUG INFO: Incoming messages from
                                           zone 1 discarded by mirrorPool
					   (if traffic is executing)
					A: Start reconciliation
M: TakeOver S: ServerReconcile-		M: Down S: ReadyToReconcileClient(5)
   Finished(10)	U: Enabled		   U: Disabled (Verified for R13p4)

					L: Waiting for external synch to
					   start.....
					L: DEBUG INFO: STUCK ON OBJECT...
					   (if traffic is executing)
					L: Mirroring: xx committed. In queue:...
					   (if traffic is executing)
					AL: Out of sync (backlog)
					    (if traffic is executing)

(Traffic will be replicated, but the replications will get stuck, since an
 external sync is required to get back on track. Possible for traffic to be
 executed in Zone 1 only. Yellow load in the TelORB processor load viewer in
 Zone 2, if traffic is executing.)

A: Create backup
   (Do not start remote sync)
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
					N: External Sync Started
					N: External Sync Succeeded
					N: Backup Started
					N: Backup Succeeded
					AL: Reconciliation Needed cleared
					AL: Out of sync cleared (no backlog)
					   (if traffic is executing)
M: TakeOver S: ReadyToGiveBack(11)	M: Down S:ReadyToTakeBack(12)
   U:Enabled				   U: Enabled
A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

The scenario below may also be performed when the zones are not in netshared
mode, i.e. perform the actions that are described for Zone 1 in the zone that
is in TakeOver mode and the actions that are described for Zone 2 in the zone
that is in Down mode.

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Add e.g. DU suites 533575 0-910
   (Owner Zone 1 and backup Zone 2 should be used for all added DUs)
A: Add e.g. DU suites 537861 0-0
A: Install replication map
A: Create backup
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
					A: Install replication map
					A: Create backup

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

DUs 533575 and 537861 were set as netshared before, but they should not be set
as netshared any longer.

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Deactivate links
					A: Deactivate links
A: TakeOver
					A: TakeOver
A: Remove DU suites (e.g. 533575 0-910)
A: Remove DU suites (e.g. 537861 0-0)
					A: Remove DU suites (e.g. 533575 0-910)
					A: Remove DU suites (e.g. 537861 0-0)
A: Activate links
					A: Activate links
M: TakeOver S:Idle(0) U:Enabled		M: TakeOver S:Idle(0) U:Enabled
					A: Transit to down
M: TakeOver S:Idle(0) U:Enabled		M: Down S: Idle(0) U: Enabled
					A: Start reconciliation
A: Create backup
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
M: TakeOver S: ReadyToGiveBack(11)	M: Down S:ReadyToTakeBack(12)
   U:Enabled				   U: Enabled
A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Start SS7 traffic
A: Start population/depopulation
A: Create backup
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

For R13 and higher, use the NetRed card in the TelORB Manager to check which
DU suites that are set as being netshared in the TelORB zone.

For releases earlier than R13, do as follows to check which DU suites that are
set as being netshared in the TelORB zone:
- Go to directory /opt/Scheduler/etc/ on IO processor 1 (or 2) and run the file
  ListDuSuite.ksh as follows:
    ./ListDuSuite.ksh

- Example of printouts:
    List DU suites:
      to8io1:etc>./ListDuSuite.ksh
      0 ClassID 1001791 low 0 high 0 owner 1 backup 2
      1 ClassID 1001791 low 1 high 1 owner 2 backup 1
      2 ClassID 1001791 low 2 high 11 owner 1 backup 2
      3 ClassID 524600 low 0 high 99 owner 1 backup 2
      4 ClassID 1001515 low 0 high 99 owner 1 backup 2

    Add DU suites:
      to8io1:etc>./AddDuSuite.ksh ../config/Jam2_0_pots.config
      ClassID 536993 low 0 high 0 owner 1 backup 2
      ClassID 531462 low 0 high 0 owner 1 backup 2
      ClassID 531250 low 0 high 0 owner 1 backup 2
      ClassID 531463 low 0 high 0 owner 1 backup 2
      ClassID 530020 low 0 high 0 owner 1 backup 2
      ClassID 530024 low 0 high 0 owner 1 backup 2
      ClassID 530022 low 0 high 0 owner 1 backup 2
      ClassID 530028 low 0 high 0 owner 1 backup 2
      ClassID 534282 low 0 high 0 owner 1 backup 2
      ClassID 534284 low 0 high 0 owner 1 backup 2
      ClassID 534280 low 0 high 0 owner 1 backup 2
      ClassID 530513 low 0 high 0 owner 1 backup 2
      ClassID 530195 low 0 high 0 owner 1 backup 2
      ClassID 530456 low 0 high 0 owner 1 backup 2
      ClassID 530173 low 0 high 910 owner 1 backup 2
      ClassID 527799 low 0 high 910 owner 1 backup 2
      ClassID 527801 low 0 high 910 owner 1 backup 2
      ClassID 536070 low 0 high 0 owner 1 backup 2
      ClassID 530026 low 0 high 0 owner 1 backup 2
      ClassID 527807 low 0 high 0 owner 1 backup 2
      ClassID 537201 low 0 high 0 owner 1 backup 2
      ClassID 527803 low 0 high 0 owner 1 backup 2
      ClassID 524713 low 0 high 0 owner 1 backup 2
      ClassID 524717 low 0 high 0 owner 1 backup 2
      ClassID 530552 low 0 high 0 owner 1 backup 2
      ClassID 524715 low 0 high 0 owner 1 backup 2
      ClassID 527805 low 0 high 0 owner 1 backup 2
      ClassID 530030 low 0 high 0 owner 1 backup 2
      ClassID 527809 low 0 high 0 owner 1 backup 2
      ClassID 536004 low 0 high 0 owner 1 backup 2
      ClassID 535275 low 0 high 0 owner 1 backup 2
      ClassID 524879 low 0 high 0 owner 1 backup 2
      ClassID 530032 low 0 high 0 owner 1 backup 2
      ClassID 533560 low 0 high 0 owner 1 backup 2
      ClassID 530163 low 0 high 910 owner 1 backup 2
      ClassID 524797 low 0 high 0 owner 1 backup 2
      ClassID 524683 low 0 high 910 owner 1 backup 2


Hints:
  - If the directory /opt/Scheduler/ and/or the file ListDuSuite.ksh do/does not
    exist on e.g. IO processor 1, copy the directory and its contents from e.g.
    to7io1 as follows:
      Tar the directory /opt/Scheduler/ on e.g. to7io1 and then ftp it directly
      to the target IO processor (you have to have superuser privileges (su)).
  - If the reply is "/opt/jre/bin/java:  not found", the link to jdk is missing.
    Write the following on IO1 at /opt/:
      su                       (Enter superuser mode)
      ln -s jdk1.1.7B jre      (Set link from jre to the correct version of jdk)
      exit                     (Exit superuser mode)

This section describes backing of the database of both zones to older version.

Zone 1 (Default primary)      	        Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
					A: Start reconciliation
					A: Perform ext sync from an old backup
					   (+ aut backup)
M: TakeOver S: ReadyToGiveBack(11)	M: Down S:ReadyToTakeBack(12)
   U:Enabled				   U: Enabled
					A: TakeOver
M: Down S: Idle(0) U: Enabled		M: TakeOver S: Idle(0) U: Enabled
A: Start reconciliation
M: Down S: ReadyToReconcileClient(5)	M: TakeOver S: ServerReconcile-
   U: Enabled				   Finished(10) U: Enabled
					A: Create backup
					A: Copy backup to Zone 1
A: Perform ext sync (+ aut backup)
M: Down S: ReadyToTakeBack(12)		M: TakeOver S: ReadyToGiveBack(11)
   U: Enabled				   U: Enabled
A: TakeOver
M: TakeOver S: Idle(0) U: Enabled	M: Down S: Idle(0) U: Enabled
					A: Start reconciliation
M: TakeOver S: ServerReconcile-		M: Down S: ReadyToReconcileClient(5)
   Finished(10)	U: Enabled		   U: Enabled
					L: Waiting for external synch to
					   start.....
A: Create backup
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
M: TakeOver S: ReadyToGiveBack(11)	M: Down S:ReadyToTakeBack(12)
   U:Enabled				   U: Enabled
A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

Note: This function is valid from AD12 and higher.

This section describes one way of testing the function Remote Sync: Quick sync.

Zone 1 (Default primary)      	        Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Start Java Demo application
   (E.g. with the values Java, 0, 3,
   300000, 3000)

A: Introduce a small database discrepancy between the two zones, by either
   reloading a TelORB processor in the standby zone, or by disconnecting the
   network redundancy links between the zones for a short period of time.

					AL: Out of sync (backlog)
A: Start Remote Sync
   (A backup will be generated and
    a quick sync will start)
N: Remote Sync Started
N: Backup Started
N: Backup Succeeded
N: Remote Sync Succeeded

   (- If quick sync is not possible, i.e. too many database objects differ,
      the notification "Remote Sync Requires External Sync" is received.
      In this case, an external sync is required.
    - If quick sync fails, e.g. if another task that interferes with quick
      sync is executing, the notification "Remote Sync Failed" is received.
      In this case, the remote sync function ends here).

L: REMOTE SYNCH RESULT
   QuickSynch succeeded (1243,0): zones
   are in synch
   (1243 = number of differing objects
    that have been updated, 0 = number
    of tombstones, i.e. deleted objects)
					N: Backup Started
					AL: Out of sync cleared
					N: Backup Succeeded
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

Hints
-----
Check NetRed remote sync values, e.g. RSAllowedDelay, RSLimit, etc.:
http://134.138.xx.101:5557/env/printenv     (Adjust xx to valid network address)
                                            (Enter any TelORB processor)

Note: This function is valid from AD12 and higher.

This section describes one way of testing the function Remote Sync: External
sync.

Zone 1 (Default primary)      	        Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Start Demo application
   (E.g. with the values 0, 3,
   300000)
A: Start Java Demo application
   (E.g. with the values Java, 0, 3,
   300000, 3000)

A: Introduce a large database discrepancy between the two zones, by e.g.
   disconnecting the network redundancy link between the zones for a longer
   period of time (~3 minutes, depending on the amount of traffic)

L: Network Redundancy link shut down	L: Network Redundancy link shut down
					AL: Out of sync (backlog)
A: Start Remote Sync
   (A backup will be generated and
    a check if a quick sync is
    possible to perform is performed)
N: Remote Sync Started
N: Backup Started
N: Backup Succeeded
N: Remote Sync Requires External Sync

   (- If quick sync is possible, i.e. not too many database objects differ,
      the notification "Remote Sync Succeeded" is received. In this case, no
      external sync is required and the test will not be satisfactory.
    - If quick sync fails, e.g. if another task that interferes with quick
      sync is executing, the notification "Remote Sync Failed" is received.
      In this case, the remote sync function ends here and the test will not
      be satisfactory)

L: REMOTE SYNCH RESULT
   Failed synching with zone 2
A: Copy the backup, that was created
   above, to Zone 2
					A: Perform ext sync (+ aut backup)
					N: External Sync Started
					N: External Sync Succeeded
					N: Backup Started
					N: Backup Succeeded
					AL: Out of sync cleared (no backlog)
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

Note: This function is valid from AD12 and higher.
In R13 it is possible to perform Smooth TakeOver from any of the zones.

It is possible to start traffic execution in both zones simultaneously, but
only traffic in the default primary zone (or the zone in TakeOver mode) will be
successful, whilst traffic in the default standby zone (or the zone in Down
mode) will be rejected.

When switching sides between the zones, no backlog should occur.


Smooth TakeOver and back
========================

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
   Traffic execution
					A: Perform a Smooth TakeOver
M: Down S: ReadyToTakeBack(12)		M: TakeOver S: ReadyToGiveBack(11)
   U: Enabled				   U: Enabled
					   Traffic execution

( If smooth TakeOver fails:
  M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled )

					A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
   Traffic execution

( If GiveBack fails:
  M: Down S: ReadyToTakeBack(12)	M: TakeOver S: ReadyToGiveBack(11)
     U: Enabled				   U: Enabled )

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs


One way of testing the function Smooth TakeOver
===============================================

Not yet verified!

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled
A: Start Demo Bank application
   (E.g. with the values 3, 3, 300000)
					A: Start Demo Bank application
					   (E.g. with the values 3, 3, 300000)
					A: Perform a Smooth TakeOver before any
					   of the Demo Bank applications start
					   to calculate sum of accounts
M: Down S: ReadyToTakeBack(12)		M: TakeOver S: ReadyToGiveBack(11)
   U: Enabled				   U: Enabled

( If smooth TakeOver fails:
 M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled )

A: Stop Demo Bank application after	A: Stop Demo Bank application after
   some time. After calculation of  	   some time. After calculation of
   account sum, check balance which	   account sum, check balance which
   should be zero			   should be zero
					A: Start Demo Bank application
					   (E.g. with the values 3, 3, 300000)
A: Start Demo Bank application
   (E.g. with the values 3, 3, 300000)

					A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

( If GiveBack fails:
 M: Down S: ReadyToTakeBack(12)		M: TakeOver S: ReadyToGiveBack(11)
    U: Enabled				   U: Enabled )

A: Stop Demo Bank application after	A: Stop Demo Bank application after
   some time. After calculation of  	   some time. After calculation of
   account sum, check balance which	   account sum, check balance which
   should be zero			   should be zero

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

This section deals with what to do when the network redundancy states in the
zones have strange values.


Zone 1: State = Idle(0)  -  Zone 2: State = ReadyToReconcileClient(5):

Zone 1 (Default primary)		Zone 2 (Default standby)
------------------------------------	------------------------------------
M: ?   S: Idle (0) U: Enabled		M: ?   S: ReadyToReconcileClient(5)
				   	U: Enabled
					A: Start reconciliation
M: TakeOver S: ServerReconcile-		M: Down S: ReadyToReconcileClient(5)
   Finished(10)	U: Enabled		   U: Enabled
					L: Waiting for external synch to
					   start.....
A: Create backup
A: Copy backup to Zone 2
					A: Perform ext sync (+ aut backup)
M: TakeOver S: ReadyToGiveBack(11)	M: Down S:ReadyToTakeBack(12)
   U:Enabled				   U: Enabled
A: GiveBack
M: Netshared S: Idle(0) U: Enabled	M: Netshared S: Idle(0) U: Enabled

Legend
------
A=Action, AL=ALarm, L=Log printout, M=Mode, N=Notification S=State, U=statUs

See Remote Sync: External sync.

The following e-mail will be translated to English later:

Alltså, huvudprylen i patch10 är att klara processoromladdning 
under extern synch. Men jag tycker att "vanlig" processor-
omladdning måste motioneras ganska mycket också innan patch10 
skickas iväg. 
Jag tänkte här försöka beskriva vad som *ska* hända när man får
processoromladdning under extern synch:

1. Trafikprocessor bootar om:
=============================

Avser processorer som inte ingår i PlgLoaderPool (d v s processor 
3-n i våra system). Om processor 3-n bootar om under extern synch 
är tanken att extern synch:en ska fortsätta och lyckas (den efter-
följande backup:en kommer dock att misslyckas). När processor 3-n 
kraschar kommer CM:en att göra oplanerad omkonfigurering samtidigt 
som extern synch:en pågår men den kraschade processorn kommer inte 
att bli uppladdad förrän extern synch:en är klar. Detta betyder alltså 
att så fort den oplanerade omkonfigureringen är gjord ska databasen vara 
fullt tillgänglig igen. Vet inte riktigt hur man testar att så är 
fallet......

2. CM processor bootar om:
==========================

Avser processor 1 eller 2 i våra system. Om man inte vet på vilken 
processor CM ligger kan man gå in via telnet demonen och göra:
  > cat SWS/CM

or via WWW, e.g. http://134.138.xx.101:5557/SWS/CM  (Adjust xx to valid network
                                                     address)
                                                    (Enter any TelORB processor)

där står angivet på vilken processor CM-master finns.  
Om CM:en kraschar under extern synch är tanken att synch:en ska avbrytas 
helt och systemet kan direkt börja ägna sig åt den kraschade processorn. 
Extern synch:en räknas som misslyckad.  

3. NetRedController:n kraschar:
==============================
NetRedController:n är en process som vanligtvis hamnar på processor 2. 
Det är denna process som har huvudansvaret för rekonsilieringsflödena. 
Om NetRedController-processen kraschar under pågående extern synch 
kommer synch:en att fortsätta (den efterföljande backup:en kommer dock 
inte att göras). Synch:en i sig räknas som lyckad (om inga andra 
komplikationer uppstår). Nu kan det ju vara så CM:en och
NetRedController:n 
hamnar på samma processor och om då "deras" processor bootar om blir det 
(naturligtvis) som om CM processor (fall 2 ovan) bootar om.

(Source: E-mail from Stefan Näslund, 1999-08-31)

Marcel Robert (LMC) wrote (slightly modified by Michel):

Test cases that will be used by SWB to validate the Network Redundancy
functionality:

Test 1	Reload of standby zone

        Primary and standby are active. System is in NetShared mode.

*       Zone reload the standby (The primary is not affected by the loss of
	the standby)
*       Standby goes through reconciliation
*       System goes back to NetShared mode

Test 2	Reload of primary zone

        Primary and standby are active. System is in NetShared mode.

*       Zone reload the primary
*       Standby performs a takeover and starts to handle traffic
*       Default primary goes through reconciliation
*       Default primary automatically takes over once the reconciliation is
	completed
*       Manually initiate the reconciliation on the standby
*       Default standby goes through reconciliation
*       System goes back to NetShared mode

Test 3	Loss of contact between the zones

        Primary and standby are active. System is in NetShared mode.

*       Disconnect the inter node links
*       Primary performs a takeover and continues to handle the traffic
*       Standby performs a takeover and becomes ready to handle traffic
*       In the standby, perform a transit to down
*       Reconnect the links
*       Manually initiate the reconciliation on the standby
*       Default standby goes through reconciliation
*       System goes back to NetShared mode

        Test case 14.008 from TACOS:
          Primary and standby zones are active. System is in NetShared mode.

          Disconnect the links between zones.
          Messages in all traffic processors "Network Redundancy link shutdown".
          No load in standby z2.
          Status z1 netshared, status z2 netshared.
          Reconnect the links after approx. 2 minutes.
          Backlog in 100% yellow load in traffic proc. standby z2.
          Takeover in z1.
          Primary performs a takeover and continues to handle the traffic.
          Standby goes to down.
          Manually initiate the reconciliation on the standby
          Default standby go throught reconciliation.
          Giveback to z2.
          System goes back to NetShared mode

Test 4	SS7 failure

        Primary and standby are active. System is in NetShared mode.

*       Disable SS7 on the primary
*       Standby performs a takeover
*       Re-enable the SS7 on the primary
*       Manually initiate the reconciliation on the primary
*       Default primary automatically takes over once the reconciliation is
	completed
*       Manually initiate the reconciliation on the standby
*       Default standby goes through reconciliation
*       System goes back to NetShared mode

Test 5	SS7 failure and backup queues (90 MB) filled up

        Primary and standby are active. System is in NetShared mode.

*       Disable SS7 on the primary
*       Standby performs a takeover
*       Re-enable the SS7 on the primary
*       Disable the backup transfer capapility (In the standby, chmod 644
	TransferBackup.ksh)
*       Wait for the backup queues (90 MB) to fill-up. This should force a
	new reconciliation to start
*       Re-enable the backup transfer capapility (In the standby, chmod 755
	TransferBackup.ksh)
*       Default primary automatically takes over once the reconciliation is
	completed
*       Manually initiate the reconciliation on the standby
*       Default standby goes through reconciliation
*       System goes back to NetShared mode

Test 6	Back the zones to old backup

        Primary and standby are active. System is in NetShared mode.

*       Deactivate the links on the primary
*       Deactivate the links on the standby
*       Unload the Scheduler on both IO processors of the standby
*       Unload the Scheduler on both IO processors of the primary
*       Activate an old backup on the standby
*       Zone reload the standby
*       Re-activate the links on the standby
*       Re-activate the links on the primary
*       Load the Scheduler on both IO processors of the primary
*       Load the Scheduler on both IO processors of the standby
*       Perform a manual takeover on the standby
*       Manually initiate the reconciliation on the primary
*       Default primary automatically takeover once the reconciliation is
	completed
*       Manually initiate the reconciliation on the standby
*       Default standby goes through reconciliation
*       System goes back to NetShared mode

Test 7	Back the database of both zones to older version (External
        synchronization from old backup)

        Primary and standby are active. System is in NetShared mode.

*       Deactivate the links on the primary
*       Deactivate the links on the standby
*       Unload the Scheduler on both IO processors of the standby
*       Unload the Scheduler on both IO processors of the primary
*       Manually initiate the reconciliation on the standby
*       Perform a manual external sync in the standby using an old backup
*       Re-activate the links on the standby
*       Re-activate the links on the primary
*       Load the Scheduler on both IO processors of the primary
*       Load the Scheduler on both IO processors of the standby
*       Perform a manual takeover on the standby
*       Manually initiate the reconciliation on the primary
*       Default primary automatically takeover once the reconciliation is
	completed
*       Manually initiate the reconciliation on the standby
*       Default standby goes through reconciliation
*       System goes back to NetShared mode

Stefan Näslund's comments plus Marcel Robert's comments (slightly modified by Michel):

 
Test 3:

SN: I don't like the fact that you use 'transitToDown'. It's OK for
    test purposes like this, but otherwise try to avoid 'transitToDown'.
    Anyway, when you start the reconciliation of the standby (bullet 6)
    it will change mode to DOWN automatically.

    What can we do to put the database in read only mode ?

MR: Yes, I guess you're right! You have to in DOWN mode to be able 
    to do 'startReconciliation'. 
    Thus, you have to 'transitToDown'.......


Test 6:

SN: When you have reloaded the standby zone (bullet 6) the links will be
    activated again since the links probably were activated on the old
    backup. Hence, the standby will be able to contact the primary but
    the primary will not be able to talk back to the standby.
    The standby will try 10 times with 10 seconds interval before it
    gives up. Before the standby gives up the links on the primary should
    not be re-activated. If so, an ordinary reconciliation will take place.

    What can we do to prevent to auto reconciliation ?

MR: Wait 10*10 seconds before re-activating the links on the primary node.

    Why do we have reconciliation ? The links in the primary are deactivated.
    Should this be enough disable the reconciliation ?

Test 7:

SN: If you deactivate the links *before* you do 'startReconciliation'
    on the standby it will not work since the standby wants to talk to
    the primary when you do 'startReconciliation'.
    In this case the order should be:

    *       Unload the Scheduler on both IO processors of the standby
    *       Unload the Scheduler on both IO processors of the primary
    *       Manually initiate the reconciliation on the standby
    *       Deactivate the links on the primary
    *       Deactivate the links on the standby
    *       Perform a manual external synch in the standby using an old backup
    *       ....

MR: Ok.

(Source: E-mail from Marcel Robert with Stefan Näslund's comments, 1999-08-20)

- Activate and deactivate links can be regarded as the on and off switch of the
  network redundancy function.

- Replication of netshared DUs from the primary zone to the standby zone starts
  when the two zones have the following data:

    One of the zones (which will	The other zone (which will
    be considered primary since		be considered standby since
    its mode is TakeOver)		its mode is Down)
    ----------------------------        ---------------------------
    Mode:   TakeOver			Mode:   Down
    State:  ReadyToGiveBack(11)		State:  ReadyToTakeBack(12)
    Status: Enabled			Status: Enabled

- "Start Reconciliation" clears the database (sort of a zone reload) and can
  only be ordered in the standby zone.
  It also trigs the primary zone to create a backup, copy the backup to the
  standby zone, starts external syncing from the copied backup and creates a
  new backup in the standby zone.
  External syncing syncs the database, e.g. subscriber data.
  After "Start Reconciliation the zone status is enabled. This will maybe be
  changed in the future.

- After a zone reload of the standby zone, all netshared DUs are cleared and
  the printout "Waiting for external synch to start....." is received. But if
  the network redundancy link is deactivated before/during the zone reload, the
  standby zone will not clear its netshared data after its zone reload. 

- "Perform Sync" (External Syncing) may be performed from a backup in own zone
  to swap its database (e.g. subscriber data). Of course, the zone must be
  standby and the zone id should be set to the zone id of the remote zone.

- "Adding/Removing DU Suites" writes in the database.

- "Install Replication Map" updates the cache with configuration information
  about on which processors objects can be accessed.

- Get network redundancy information for a TelORB zone by using telnet:
    telnet 134.138.xx.101 8000              (Adjust xx to valid network address)
                                            (Enter any TelORB processor)
    cd NetRed
    cat NRC

    ( Example of printout for to15:

      Current state relative peer zone 1 is: 8 (see DnrcController.hh) 

      Time stamps (UTC) for partition [2.1] 
	       commitByMe: 2000-10-15_12:07:13 
	       peerIncludedTo: 2000-10-16_11:55:31 
	       ack: 1990-01-01_00:00:00 

      Db state for partition [2.1] is: 1

      Time stamps (UTC) for partition [1.2] 
      	       commitByMe: 2000-10-13_12:19:24 
      	       peerIncludedTo: 2000-10-16_11:55:31 
      	       ack: 1990-01-01_00:00:00 

      Db state for partition [1.2] is: 1

      Netshared data cleared (TRUE/FALSE): FALSE 

      Number of failed transactions relative peer zone 1 is: 0 

      Link to peer is working (TRUE/FALSE): TRUE 

      DnrcMirrorTailDelay = 500 [ms]

      Time stamp for latest backup = 2000-10-16_12:21:25 )


    ( Example of printout for to15 when no network redundancy is initiated:

      DnrcMirrorTailDelay = 500 [ms]

      Time stamp for latest backup = 2000-10-19_13:46:09 )

- Reloaded P3 in standby zone during an ongoing remote sync.
  Backup succeeded and remote sync required external sync
  which was initiated. OK.
  After a short while, backlog appeared in P3 in standby zone,
  which is OK. A new remote sync was initiated. OK without
  external sync. (R13p5)

General
 (Updated: 2002-11-12)

It is possible to get a list of all the software that exists in a TelORB system.
This list is put in a file called the .config file and it is situated below
/opt/telorb/axe/loadingGroup01_1/ on IO processor 1.

The .config file is also used as input when e.g. creating an upgrade package.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Create a .config file
 (Updated: 2002-11-12)

- If you want to generate a new .config file from a TelORB system, simply use
  the TelORB Manager, go to the Inventory card and click the button "Create
  .config file".
  The .config file is named to reflect the current value of "NAME" in the .epct
  file for the system and is put below directory
  /opt/telorb/axe/loadingGroup01_1/ on IO processor 1.
  If the system has previously been upgraded, the .config file is named to
  reflect the name of the last used upgrade package.

"initdatapatch" is a patch-tool that patches initialData loadmodule body while
keeping the LM header intact (including the body checksum).

To change initial data in a running TelORB system (requires a zone reload or,
to avoid traffic loss, that all TelORB processors are reloaded one by one, after
the change), do the following from e.g. tos1/tos2:

1.  Go to the directory where the epct files are located, e.g.
    /home/dicostest/tosFiles/to3/ad12.2/.

2.  If the change is to be persistent, edit the affected epct file, e.g.
    telorbData.epct, with the updated initial data variable(s) (to be used at
    the next initial load).

3.  Create a new file (called "new_file" in steps 6 and 9 below) where only the
    changes are implemented, e.g. IpcOverloadRejectLevels = (100, 200, 1000)
    Comments (# and //) are automatically removed by the updating script.

4.  Add the path to where the updating script is located, if not already done:
    echo $path
    set path = (/home/dicoshack/Hack/uablrek/bin $path)

5.  Check current initial data in the file kernelConfigurationDataLm on IO1 for
    one of the TelORB processors before the file is being updated (for reference
    reasons):
    more ../axe/loadingGroup01_1/Processor3/processorConfiguration/kernelConfigurationDataLm

6.  Run the updating script "initdatapatch" on IO1 (from tos1/tos2 to get
    access to both the controlling environment and the IO processors), e.g.
    from /home/dicostest/tosFiles/to3/ad12.2/. Be sure to modify "new_file" in
    the path below to the file name that was previously specified in step 3:
    initdatapatch <new_file> ../axe/loadingGroup01_1/Processor*/processorConfiguration/kernelConfigurationDataLm
      If the response is "exec: perl5: not found", enter "source Envsettings" to
      get access to the perl interpreter and then run the updating script again.
      If the response still is "exec: perl5: not found", a link to perl5 may be
      missing. If so, do as follows on either tos1 or tos2:
         tos1:toX>su
         tos1:toX#cd /bin
         tos1:/bin#ls -l per*
         tos1:/bin#which perl
         /usr/bin/perl
         tos1:/bin#cd /usr/bin/
         tos1:bin#ls -l per*
         perl*        perl5.00404* perldoc*     
         tos1:bin#ln -s perl5.00404 perl5
         tos1:bin#exit
         exit            (Exit su mode)

7.  Check that the file kernelConfigurationDataLm on IO1 for one of the TelORB
    processors is updated correctly:
    more ../axe/loadingGroup01_1/Processor3/processorConfiguration/kernelConfigurationDataLm

8.  Check current initial data in the file kernelConfigurationDataLm on IO2 for
    one of the TelORB processors before the file is being updated (for reference
    reasons):
    more ../axe/loadingGroup01_2/Processor3/processorConfiguration/kernelConfigurationDataLm

9.  Run the updating script "initdatapatch" on IO2 (from tos1/tos2 to get
    access to both the controlling environment and the IO processors), e.g.
    from /home/dicostest/tosFiles/to3/ad12.2/. Be sure to modify "new_file" in
    the path below to the file name that was previously specified in step 3:
    initdatapatch.pl <new_file< ../axe/loadingGroup01_2/Processor*/processorConfiguration/kernelConfigurationDataLm

10. Check that the file kernelConfigurationDataLm on IO2 for one of the TelORB
    processors is updated correctly:
    more ../axe/loadingGroup01_2/Processor3/processorConfiguration/kernelConfigurationDataLm

11. To "activate" the new initial data settings, all TelORB processors in the
    system need to be reloaded. This can be achieved by either performing a
    zone reload (causes traffic loss) or by reloading all TelORB processors
    one by one (to avoid traffic loss).

12. If you want to check that the correct initial data settings are loaded into
    the TelORB system, check the initial data settings for the loading part
    (from the zone/processor reload(s)) in a console/log of one TelORB
    processor.

Note:
The updating script "initdatapatch" is located below directory
/ipims_dicos/ipims_dicos20/BS2/tbAD14p11/DICOS_IDPG/Unix_IDP/UnixLib_LM/devenv_scripts/
(Adjust tbAD14p11 to valid testbed)

To use the updating script, you must have write access rights on current
directory and on the processorConfiguration directories.

For TSP 4 and earlier, the INITAL DATA is stored in a special load module called
KernelConfigurationDataLm and is stored per TelORB processor.

General
 (Updated: 2005-10-27)

While e.g. executing test cases, it is a good idea to monitor and check for
error printouts in the TelORB processor log files.

The recommendation is to check the log files for at least the Dicos loader
processors, one Dicos non-loader processor and one Linux processor.

It may be hard to monitor the printouts in the TelORB processor consoles due
to their small window sizes, so you may want to open the processor logs
instead. These are located on the IO processors, as follows:

    TSP5
    ----
      /opt/telorb/axe/tsp/consolelogs

    TSP4
    ----
      /opt/telorb/consolelogs

In the consolelogs directory on any of the IOs, it may be worthwhile to check
the following (I will update and add more items later):

  grep -i 'DoRela' Proc*
  grep -i 'Capsule abortion' Proc*
  grep -i 'LOG_ERR' Proc*
  grep -i 'LOG_WARNING' Proc*

General
Note: The Crash Collector was introduced in TelORB in TelORB R?? to collect
error dumps, TelORB processor log files, system log, etc. for dispatch to the
support centre when failures occur.
See Crash collector for more information about the Crash Collector.

When a process (capsule) or a TelORB processor in the TelORB system crashes,
an error dump is generated. The error dumps are initially stored in the
directory /opt/telorb/dumps/ on the IO processors (see below for storage info)
and they contain information about each individual crash.
Within 5 (?) minutes, all error dumps which exist in directory
/opt/telorb/dumps/ will be packed together with crash collection data and moved
to directory /opt/telorb/crashcollector/.

There are 4 types of error dumps for Dicos:

- DicosCapsuleTextDump...
      Dump reason:  A C++ process (capsule) has crashed.
      Dump storage: On both IO processors.
      Example:      DicosCapsuleTextDump.134.138.62.103-65.

- DicosJavaDump...
      Dump reason:  A java process has crashed.
      Dump storage: On both IO processors.
      Example:      DicosJavaDump.134.138.62.103-66.

- DicosProcessorTextDump...
      Dump reason:  A TelORB processor has crashed
      Dump storage: On one of the IO processors (the IO that answers first).
                    (The OS is not reachable, since the processor is down.)
      Example:      DicosProcessorTextDump.134.138.62.103-67.

- DicosSyslog...
      Dump reason:  A TelORB processor has crashed.
                    Since the syslog is not available, due to the processor
                    crash, the dump contains information which should have been
                    transferred to the syslog.
      Dump storage: On one of the IO processors (the IO that answers first).
                    (The OS is not reachable, since the processor is down.)
      Example:      DicosSyslog.134.138.62.103-68.


      Dump storage
      ------------
      The reason why the processor and syslog dumps do not go to both IO
      processors, is that these dumps are generated on a crashed processor, i.e.
      there is no OS. All basic functions such as memory allocation, timers,
      IP-stack and sheduling simply do not exist. The dump program implements
      its own IP stack (ARP/IP/UDP/TFTP) directly on the ethernet driver (that
      is set in "polling mode"). It counts processor cycles for timing, and uses
      preallocated static data only. A bug in this code may also hang the
      processor so a manual reset (physically press the reset button) is
      required. It is much harder to extend to 2 destinations in this
      environment than in a driver or in the kernel. That's why Carlos who made
      this extension postponed this after some tries (on Ekman's
      recommendation).
      I'm definitely of the opinion that all error dumps always should end up on
      both IO processors and therefore I've strongly suggested that this
      functionality is implemented as soon as possible (2001-04-02).

To map the error dump contents to the SW code, the dump must be disassembled.
For this purpose, the program epelfaddr is used.
There are different ways to interpret (disassemble) an error dump, see below.
When sourcing and setting epconfig, it is possible to do this towards the AD or
testbed, since for both locations, the LMs have their paths to their belonging
OUs and SCCs as long as your environment has access to /ipims_dicos/.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Alternative 0 to interpret an error dump (Webelf)
There is a tool for analyzing error dumps, namely WebElf.
(I have not used this tool myself, so I don't know whether to recommend it or
not. Try it - you may like it.)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Alternative 1 to interpret an error dump (epelfaddr_dmp). Valid for TSP 5.
(Only valid for the EAB CW/OS lab)
In the EAB CW/OS lab, where e.g. pink LAN is mounted on at least IO2, it is
not necessary to copy error dumps from the IO processor to the location where 
epelfaddr will be executed.
On e.g. IO2, you can just perform the mounting, source the valid testbed, run
the epelfaddr command and point out the error dump on IO2 as exemplified below:

  To mount, follow the instructions provided in
  Mount EAB CW/OS lab environment on IOs.
  tcsh
  source /ipims_dicos/BS2/tbWP026/Setup.csh  (Do not use
                       "tsp_deliverables" in between "tbWP026" and "Setup.csh"!)

  epelfaddr_dmp -d /opt/telorb/axe/tsp/crashcollector/temp0501270906_Proc_m2_s1/DicosCapsuleTextDump.172.16.2.9-1  (Adjust path to valid crash collector file)

== == == == == == == == == == == == == == == == == == == == == == == == == ==


Alternative 2 to interpret an error dump (epelfaddr_dmp)
(Only valid for the EAB CW/OS lab)
In the EAB CW/OS lab, where tos1/tos2 is used, it is not necessary to copy
error dumps from the IO processor to the location where epelfaddr will be
executed.
You can just run the epelfaddr command from tos1/tos2 (e.g. from where you
previously built using a testbed) and point out the error dump on the IO
processor as exemplified below:
  source /ipims_dicos/BS2/tbAD14lp7.5/IP_CONF_INFO/EnvSettings
  epelfaddr_dmp -d /to29/to29io1/telorb/crashcollector/temp/DicosCapsuleTextDump...

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Alternative 3 to interpret an error dump (epelfaddr_dmp)
1. Use a tos1/tos2 shell or a local shell.
   Create a new directory below which the directory epws is created
   or go to where the system was built, e.g.
     cd /home/dicostest/tosFiles/toX/TelORB-R14-Linux-Patch4 (Adjust toX to
                                       valid TelORB system and adjust
                                       TelORB-R14-Linux-Patch4 to valid release)

2. Source the testbed which corresponds to what is loaded in the TelORB
   zone, e.g. for a clean `AD14 with Linux' release the sourcing will look as
   follows:
     source /ipims_dicos/BS2/tbAD14l/IP_CONF_INFO/EnvSettings (Adjust tbAD14l to
                                                                  valid release)
   or e.g. for an `AD14 with Linux' release including all patches up to patch 4,
   the sourcing will look as follows:
     source /ipims_dicos/BS2/tbAD14lp4/IP_CONF_INFO/EnvSettings (Adjust
                                                     tbAD14lp4 to valid release)
   Hint: If the epelfaddr command, in step 6 below, misses some LMs, it is
         recommended to delete all epconfig settings (epconfig d -a), before the
         sourcing. (If you first source the clean tbAD14l and then you source
         tbAD14lp4, the epelfaddr command might miss some LMs.)

3. Delete all epconfig settings and set environment variable:
     epconfig d -a
     setenv EP_WORKSPACE `pwd`/epws

4. If some LMs exist in the system which do not exist in the testbed, which was
   previously sourced, these LMs should also be included by using the
   epconfig command, i.e.:
     epconfig s ...

5. Fetch the dump file from one of the IO processors as follows:

   Using tos1/tos2:
     cp /toX/toXio1/telorb/dumps/dump_file . (Adjust toX to valid TelORB system)


   Using local shell:
     ftp toXioY                     (Adjust toX to valid TelORB system and ioY
                                     to valid IO processor)
     name                           (Enter name, e.g. telorb)
     psw                            (Type password)
     cd /opt/telorb/dumps/          (Go to the directory where the dumps are
                                     located)
     bin                            (Binary mode)
     get dump_file                  (Adjust dump_file to valid dump file name)
     by                             (or use "quit")  (quit ftp)

6. Interpret the dump as follows:
     epelfaddr_dmp -d dump_file     (Adjust dump_file to valid dump file name)
                                    (`epelfaddr_dmp' scans a TelORB dump file
                                     to find out what load module each address
                                     belongs to. When the load module is found,
                                     the `epelfaddr' command is run.
                                     Usage: `epelfaddr_dmp -d dumpfile'
   	                                    `-d dumpfile'   Specify dump file)
                                    (To get the result into e.g. file file.txt:
                                     epelfaddr_dmp -d dump_file > file.txt)
   Hint: If the epelfaddr command misses some LMs, see the Hint part in
         step 2 above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Alternative 4 to interpret an error dump (epelfaddr_sel)
If the call chain and loaded LMs are included in the dump, the easiest way to
interpret the dump is to use the "epelfaddr_sel" method and mark everything in
the dump as follows:

1. Use a local shell. Do not use tos1/tos2.
   Create a new directory below which the directory epws is created
   or go to where the system was built, e.g.
     cd /home/dicostest/tosFiles/toX/ad12.4/ (Adjust toX to valid TelORB system
                                             and Adjust ad12.4 to valid release)

2. Source the testbed which corresponds to what is loaded in the TelORB
   zone, e.g. for a clean AD12.4 release the sourcing will look as follows:
     source /ipims_dicos/BS2/tbAD12.4/IP_CONF_INFO/EnvSettings (Adjust tbAD12.4
                                                               to valid release)
   or e.g. for an AD12.4 release including all patches up to patch2 the sourcing
   will look as follows:
     source /ipims_dicos/BS2/tbAD12.4p2/IP_CONF_INFO/EnvSettings (Adjust
                                                    tbAD12.4p2 to valid release)
   Hint: If the epelfaddr command, in step 5 below, misses some LMs, it is
         recommended to delete all epconfig settings (epconfig d -a), before the
         sourcing. (If you first source the clean tbAD12.4 and then you source
         tbAD12.4p2, the epelfaddr command might miss some LMs.)

3. Delete all epconfig settings and set environment variable:
     epconfig d -a
     setenv EP_WORKSPACE `pwd`/epws

4. If some LMs exist in the system which do not exist in the testbed, which was
   previously sourced, these LMs should also be included by using the
   epconfig command, i.e.:
     epconfig s ...

5. Do the following:
   - Write epelfaddr_sel in the local shell, don't send it yet.
   - Either open the dump in an editor and mark the complete dump or give the
     `more' command on the complete dump and mark the complete dump.
   - Send the epelfaddr_sel command.
   Hint: If the epelfaddr command misses some LMs, follow the Hint part in
         step 2 above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Alternative 5 to interpret an error dump (epelfaddr_sel)
If information about that a dump has occurred is available in a TelORB processor
console and thereby also in the corresponding TelORB processor log file, but a
corresponding dump does not exist on any of the IO processors, interpret the
dump by using the "epelfaddr_sel" method and mark the loading part in another
valid dump for the same TelORB processor as follows:

1. Follow steps 1-4 for alternative 2 above.

2. Write epelfaddr_sel and add the addresses that are specified in the TelORB
   processor log file next to the printout "Call chain:", e.g.
   00264eea 50001674 5050464e 505073aa 50506f6a 50507847. This will result in
   a line that looks as follows:
   epelfaddr_sel 00264eea 50001674 5050464e 505073aa 50506f6a 50507847
   Before sending the epelfaddr_sel command, mark, in another window, everything
   below the printout "Init LoadModules" in any valid dump for the TelORB
   processor where the dump occurred.
   Send the epelfaddr_sel command, e.g.
   epelfaddr_sel 00264eea 50001674 5050464e 505073aa 50506f6a 50507847
   Hint: If the epelfaddr command misses some LMs, follow the Hint part in
         step 1 (2) above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Alternative 6 to interpret an error dump (epelfaddr_sel)
If the complete loading sequence for a TelORB processor where a dump has
occurred is available in a TelORB processor log file (only when a terminal
server is used), it is possible to get all available information without
consulting the actual dump.

1. Follow steps 1-4 for alternative 2 above.

2. Write epelfaddr_sel and include the addresses that are specified in the
   TelORB processor log file next to "Call chain:", e.g.
   00264eea 50001674 5050464e 505073aa 50506f6a 50507847 500060c4 0024bc89 00253e95.
   Before sending the epelfaddr_sel command, mark, in the TelORB processor
   log file, the loading sequence for the TelORB processor where the dump
   occurred.
   Send the epelfaddr_sel command, e.g.
   epelfaddr_sel 00264eea 50001674 5050464e 505073aa 50506f6a 50507847 500060c4 0024bc89 00253e95
   Hint: If the epelfaddr command misses some LMs, follow the Hint part in
         step 1 (2) above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Old alternative to interpret an error dump (epelfaddr_dmp)
Until it is possible to run epelfaddr from tos1 or tos2 do the following:
(telnet toc2?)

cd /home/dicostest/tosFiles/to3/

Edit the file Envsettings to point to the corresponding testbed that is
loaded in the TelORB system and save it with a different name, e.g.
Envsettings.tb3711 (if not already done).
source Envsettings.tb3711
mkdir slask
cd slask
ftp to3io2                        (Where to get dump from, i.e. IO1 or IO2)
telorb
psw                               (Type password)
ascii or bin??? John says bin. Mats uses ascii.
cd /opt/telorb/dumps
get _Dicos(Processor)TextDump..._
bye
ls
epelfaddr_dmp -d _Dicos(Processor)TextDump..._
  or
epelfaddr_dmp -d _Dicos(Processor)TextDump..._ > _file_

Paste the epelfaddr result into the TR.
cd ..
rm -r slask            (Remove dump file and slask directory)

(exit)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
If no loading information for a processor is available or if an error dump is
observed in the TelORB processor log available on the IO, but a  shows a dump, you can create a fake
dump and get the loading information from there. To accomplish this, just kill a
process, e.g. De2TGPT or De2GWTP, in the TelORB processor of interest, and a
dump with loading information will be produced (telnet <IP_address> 8100).
You can then add "Call chain:" information to the dump file and thereafter run
epelfaddr on it.

To execute epelfaddr if e.g. test LMs (TLMs) are in the system, just enter the
epconfig command towards where the TLM was built.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Creating error dumps for testing purposes
 (Updated: 2003-09-09)

When creating an error dump, as described below, the error dump will initially
appear in directory /opt/telorb/dumps/ on both IO processors, but will within
5 minutes be moved to directory /opt/telorb/crashcollector/ together with other
crash collected files.

- Create a DicosCapsuleTextDump error dump (a C++ process will be killed)
  (From IO1 or IO2):
    telnet 172.16.16.15 8100   (E.g. Proc_m0_s15 with Dicos OS) (Adjust IP addr)
    ps                         (List all running processes)
    Look for e.g. DdbomBackupSupervisor (or e.g. DriverAlarmProcess).
    kill <PID_for_DdbomBackupSupervisor>
      (Notification "Capsule Abortion" identifying the killed process should
       appear in the notification window.)

- Create a DicosProcessorTextDump and a DicosSyslog error dump (the taget TelORB
  processor will crash, i.e. it will perform a processor reload)
  (From IO1 or IO2):
    telnet 172.16.16.15 8100   (E.g. Proc_m0_s15 with Dicos OS) (Adjust IP addr)
    ps                         (List all running processes)
    Look for e.g. DDB Configuration Manager Agent (or e.g. JavaVirtualMachine).
    kill <PID_for_DDB Configuration Manager Agent> CONFIRM

- Create a DicosJavaDump error dump (a Java process will be killed)
  (From IO1 or IO2):
    This is probably not possible to do, since the Java processes are very
    short-lived, at least I have not succeeded to accomplish this.
    telnet 172.16.16.15 8100   (E.g. Proc_m0_s15 with Dicos OS) (Adjust IP addr)
    ps  ps  ps  ps  ps  ps     (List all running processes repeatedly)
    Look for e.g. Java Process.
    kill <PID_for_Java_Process>

General
 (Updated: 2003-10-20)

From TSP 4.0 patch 8 (tbAD14lp8) and soon also TSP 5.0, the core error dump
analysis function for Linux has been moved into epelfaddr_dmp.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Usage
 (Updated: 2003-10-20)

epelfaddr_dmp -h gives the following information:

Usage: epelfaddr_dmp [-v] [-h] [-l #] -d <Dicos dump file>
           elelfaddr_dmp [-h] [-g] [-f <program>] -d <Linux dump file>
	-v		Verbose
        -g              Start debug session
        -f              Executable to debug (default is LmStarter)
	-h		This printout
	-K		Do not Keep going
	-l #		Disassembly length (default 4)
	-d dumpfile	Specify the Dump file.
	-S              Skip write permission test (NT admin only)

Note the two new flags, -g and -f, that are specific to Linux error dump files.
The -g flag will drop you into a gdb session. From this you can move around in
the stack and examine local and global variables.

The type of the error dump file is checked to see if it is an ELF file or not.
If ELF, it is assumed to be an error core dump file from Linux. Otherwise it is
treated as a normal Dicos error dump (see Dicos error dumps above).

(Source: E-mail from Per Karlsson, 2003-10-20)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Linux kernel crash dumps
 (Updated: 2005-02-28 for SLES9 in TSP 5.1)

E.g. LinuxProcessorDump-172.16.0.151-2005-02-27-21\:22.tgz.

The dump server is included in the SLES distribution and is started with a
start script in the normal fashion (man 8 netdump and/or man 8 netdump-server).
The netdump-server stores the dumps in /var/spool/crash which is not
configurable. TSP's crashcollector then takes the dumps and creates a crash dump archive (tar) file in /opt/telorb/axe/tsp/crashcollector/.

The dump can be interpreted (analyzed) with the lcrash program which requires
some kernel information files, i.e. System.map and Kerntypes.

Interpret the dump as follows (example values):
On IO:
  cd /opt/telorb/axe/tsp/crashcollector/
  tar zxf crashcollector0502272125_Proc_m2_s1.tar.Z
  ls -l
  cd temp0502272125_Proc_m2_s1/
  ls -l
  tar zxf LinuxProcessorDump-172.16.0.151-2005-02-27-21\:22.tgz --force-local
  ls -l
  cd 172.16.0.151-2005-02-27-21:22
  ls -l
    (The following files should exist (example): Kerntypes-2.6.5-tsp1,
    System.map-2.6.5-tsp1, vmcore.
    If the file README.vmcore exists instead of the vmcore file, and the
    contents of it is "No vmcore saved. Probably because the limit
    'max concurrent dumps' have been reached.", there should be another
    LinuxProcessorDump which occurred at the same time. This is because only
    one dump can be handled, even though two or several dumps occur
    simultaneously. The other LinuxProcessorDump should exist in the same
    crash collector directory, but if it does not, it may exist in another
    closely related (timewise) crash collector directory.)
  /sbin/lcrash -r -d vmcore -m System.map-2.6.5-tsp1 -t Kerntypes-2.6.5-tsp1 
    -or-
  /sbin/lcrash -r -d vmcore -m /boot/System.map-2.6.5-tsp1 -t /boot/Kerntypes-2.6.5-tsp1 

  (From uabvak: /sbin/lcrash -m /boot/System.map-2.4.21-R2A42 -t /boot/Kerntypes-2.4.21-R2A42 -d vmcore)

Try this command when applicable:
gzip -dc /var/log/messages-20050302.gz | grep netdump | less

First stored in /var/spool/crash/.
Then in /opt/telorb/dumps/.
Then renamed and moved to crashcollector.

(Did not work when I tried it, due to "Dump level: 0x7 Failed".)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Usage
 (Updated: 2004-04-30)

This subsection will be updated at a later occasion, when I have more info.

Bring a core dump into gdb for interpretation:
  zcat core.t978542318.hProc_m0_s1.u0.g0.s6.p3267.java.gz.172.16.0.1-1 > file_name
  gdb <binary_where_you_built_from> <output_from_zcat>
  bt        (backtrace)

(Source: Info from Sverker Wiberg, 2004-04-30)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Further usage info
 (Updated: 2003-12-11)

This subsection will be translated at a later occasion.

Har nu testat epelfaddr_dmp på core-dumpar (Linux) med hjälp av Per
Karlsson. Såhär går man tillväga:

1) Se till att du kör på en linux-burk (t ex tos2)
2) Kopiera över en core-dump från crashcollectorn, lägg till .gz på slutet av
   filen
3) gunzip filnamn (ex gunzip core.gz)
4) Sourca tbAD15LSV-505.1
5) epconfig s
/ipims_dicos/BS2/devenv4.0/DevEnv_IDPG/DeploymentTools_IDP/DeploymentToolsLib_LM/
6) epelfaddr_dmp -d filnamn (ex epelfaddr_dmp -d core)

Det gick inget vidare med den java-dump jag försökte på först men bättre på en
 lmstarter-dump.

epconfig behöver antagligen bara användas tills vi har byggt om nästa gång(?).

(Source: E-mail from Krister Nilsson, 2003-11-21)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Creating error dumps for testing purposes
 (Updated: 2003-12-16)

When creating an error dump, as described below, the error dump will initially
appear in directory /opt/telorb/dumps/ on both IO processors, but will within
5 minutes be moved to directory /opt/telorb/crashcollector/ together with other
crash collected files.

Create a core crash on a TelORB processor with Linux OS (from IO1 or IO2):

Also, see TelORB processor with Linux OS, some useful commands.

1. Log in to Linux processor.
2. sleep 10
3. Ctrl-z (Put the sleep process into pause mode. Must be performed within 10
           secs)
4. jobs
5. kill -SEGV %1 (%1 = "PID" for the sleep process)
6. fg (activate the sleep process)
   Printout:
     "sleep 10
      Segmentation fault (core dumped)"
   A Linux core dump will end up in the directory /opt/telorb/dumps/ on the IO
   processors and a notification with the name "Capsule Abortion" should be
   obtained.

Maybe the following is a better way to get a core crash on a Linux processor:

In order to get a Linux core dump, kill the "LinuxDicosSyslogServer" process on
any of the Linux processors as follows:
- Log in to a Linux processor.
- Find the "LinuxDicosSyslogServer" process:
    ps
- Kill the "LinuxDicosSyslogServer" process:
    kill -SIGABRT <id>.
  I have not tried this myself yet.

-- -- -- -- -- --

Create a kernel crash on a TelORB processor with Linux OS:

Also, see TelORB processor with Linux OS, some useful commands.

1. Copy the program crash.o to e.g. IO processor 1 and put it below
   /opt/telorb/axe/loadingGroup01_1. (The test module crash.o, provided by
   Jörgen Karlsson, can be fetched from /home/uabmsu/telorb/test_programs.
   It works for TSP 4.0 (patch8). If you are using another release, e.g.
   TSP 5.0, ask Jörgen if this version of the crash.o test module will work.) 

2. Log in to a Linux processor (preferably log in using a serial cable with
                                tip or minicom to be able to see the inital
                                printouts when the crash occurs, but this is
                                not necessary):
     From an IO processor (or execute steps 2-5 using tip/minicom from an IO):
       telnet <IP_address_to_a_Linux_processor>
       login: telorb

3. Enter superuser mode:
     su -
     Password: ********

4. cd /opt/telorb/axe/loadingGroup01_1/

5. insmod -f crash.o

   (Or enter e.g. /sbin/insmod -f /opt/telorb/axe/loadingGroup01_1/crash.o)

    "Warning: loading crash.o will taint the kernel: no license
       See http://www.tux.org/lkml/#export-tainted for information about tainted
       modules
     Warning: loading crash.o will taint the kernel: forced load"

   The Linux processor will crash and a Linux crash dump will appear on the
   IO processor which is specified as the first IO processor in
   dumpServerAddress in the /opt/telorb/etc/dhcpd.pxe.conf file.
   (E.g. "option dumpServerAddress    172.16.9.1, 172.16.0.129;" will put the
    crash dump on 172.16.9.1).
   The crash will end up in directory /opt/telorb/dumps/ to later become crash
   collected in the directory /opt/telorb/crachcollector/.

   The same scenario as described above can preferably also be used when
   using uabnick's lock.o module for testing the Linux watchdog.
   I've started to write these instructions below, but they need to be completed
   (also see TACOS test case 02.010):

     1. Copy the kernel module lock.o to e.g. IO processor 1 and put it
        below /opt/telorb/axe/loadingGroup01_1.

     2. Log in to a Linux TP.

     3. Enter superuser mode.

     4. cd /opt/telorb/axe/loadingGroup01_1/

     5. insmod -f lock.o
          (Or enter e.g.
          /sbin/insmod -f /opt/telorb/axe/loadingGroup01_1/lock.o)

     6. Ask uabnick for further instructions and add the instructions here.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Some info about the kernel crash log
 (Updated: 2004-01-29)

Example of crash dump on IO processor:
  gtar zxf 172.16.8.21-2004-01-22-16:08.tgz

Unpack the tgz file with gtar command and "--force-local" flag as
follows:
  gtar zxf 172.16.8.21-2004-01-22-16:08.tgz --force-local

    (--force-local is needed for an archive file which is local even if it has
     a colon)

Below e.g. the directory 172.16.8.21-2004-01-22-16:08, you will find a crash
log. This log can be read by the "ksymoops" command with "-m" flag pointing
to the "/boot/System.map" file located on the traffic processor that has
crashed.
(Source: E-mail from Jorge Martinez, 2004-01-29, slightly modified)

General
 (Updated: 2001-05-07)

Purpose of the Crash Collector: Provide a mechanism to collect error dumps,
                                TelORB processor log files, system log, etc.
                                for dispatch to the support centre when failures
                                occur.

Goal of the Crash Collector:    Reduce maintenance burden by making sure that
                                correct information is saved automatically for
                                later troubleshooting.

Once an error dump happens, it remains in place (/opt/telorb/dumps on IO) until
the Crash Collector notices it. The Crash Collector is a daemon which scans the
system every 5 minutes (this value is configureable) to see whether it can find
new crashes.
The types of crashes that the Crash Collector triggers on is configureable. If
it can, the Crash Collector then creates and compresses a tar file of the
relevant error dump and logs and associated files. All error dumps found will be
considered part of the same problem and will be packed together.
Dumping is subject to "burst protection" to protect against flooding. When burst
protection is initiated, a restriction of one error dump per second is put in
place. 
To ensure that the IO processors' file space is not filled with needless
collections, the Crash Collector deletes any collections that are older than 30
days. This value is also configureable.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Unpack a crash collector file
 (Updated: 2004-06-22)

Note that the directory for storing crash collector files has changed in TSP 5
to:
  /opt/telorb/axe/tsp/crashcollector/

On the IO processors:
  cd /opt/telorb/crashcollector/ (TSP 4 and earlier)
    -or-
  cd /opt/telorb/axe/tsp/crashcollector/ (TSP 5 and later)
  ls -lrt
    Example of printout:
      total 7186
      -rw-r--r--   1 telorb   telorb    455331 Aug 13 14:18 crashcollector0108131418.tar.Z
      -rw-r--r--   1 telorb   telorb    452887 Aug 13 20:58 crashcollector0108132058.tar.Z

  Unpack the crashcollector file by either doing as follows (v flag may be
  omitted):

  tar zxvf crashcollector0108132058.tar.Z

  or:

  uncompress -c < crashcollector0108132058.tar.Z | tar -xvf - (Uncompress a crash
                                                               collector file)
  or:

  uncompress crashcollector0108132058.tar.Z                   (Uncompress a crash
  tar xvf crashcollector0108132058.tar                          collector file)

  or:

  gtar zxvf crashcollector0108132058.tar.Z   (If gtar is available on IO)

    (For all alternatives above, adjust crashcollector0108132058.tar.Z to
     valid file name)

  The result from the unpack command(s) is stored in directory
  /opt/telorb/crashcollector/temp/.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check for certain strings in crash collector file(s)
 (Updated: 2004-01-20)

  cd /opt/telorb/crashcollector/

Check one crash collector file for e.g. core dumps:
  gtar zvft crashcollector0401191719.tar.Z | grep core

Check all crash collector files for e.g. core dumps:
  gtar zvft *.tar.Z | grep core

Search for the reason for all DicosCapsuleTextDumps in the crash collector's
temp directory after unpacking a crash file:
  grep Reason DicosCapsuleTextDump*

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Files for collection
 (Updated: 2001-09-10)

If an error dump exists in the directory /opt/telorb/dumps/, the Crash Collector
collects the following files (the scanning of the dumps directory takes place
every 5 minutes):
 
- Error dump file(s), e.g. DicosCapsuleTextDump.172.16.0.13-1, from
  directory /opt/telorb/dumps/.

- The telorb.conf file from directory /opt/telorb/etc/ on local IO.
  (Collected as telorb.conf.<internal_IP_address_of_local_IO>, e.g.
  telorb.conf.172.16.0.129).

- All .epct files from directory /opt/telorb/system/ on local IO.

- All syslog files from directory /opt/telorb/.
  (I.e. all files beginning with "syslog".)

- All TelORB processor log files, i.e. Proc_mX_sY and Proc_mX_sY.b for each
  TelORB processor from directory /opt/telorb/consolelogs/.
  The rest of the files and directories below /opt/telorb/consolelogs/ are
  also collected.

- The kernelConfigurationDataLm file in the directory
  /opt/telorb/axe/loadingGroup01_Z/Proc_mX_sY/processorConfiguration/ for each
  TelORB processor.

- Files services_list_IO.out in the directory /opt/telorb/etc on both IOs.
  (This is the only file that is by default collected from the peer IO.
  Collection of other files from the peer IO is configureable.)
  If no services list defined:
    more temp/peeretc/README
    "no services list command given in crashcollector.conf file so no
     serviceslist file will be generated for peer io."
  I have not seen the services_list_IO.out files and I don't know what these
  files contain and if they should be crash collected, and if they should, how
  to specify this in the /opt/telorb/etc/crashcollector.conf file. uabgros does
  not know either (2003-12-16).

If the crashcollector is configured to also collect files from the peer IO the
following files will be collected from the other IO processor: 

- All files and directories below /opt/telorb/consolelogs/.
  (Will be stored in directory temp/peerconsolelogs/)

- All .epct files from directory /opt/telorb/system/.
  (Will be stored in directory temp/peersystem/)

- All services_list_IO.out files....
  (Will be stored in directory temp/peeretc/)

Example of the crashcollector.conf file located below /opt/telorb/etc/ on both
IOs:

  # where RSYNC is located
  RSYNC=/opt/rsync

  # the parameters which we need to pass to rsync
  RSYNC_OPTIONS="-v -L -z -p --stat --delete --times -r --timeout=60"

  # TelORB's root dir
  TELORB_ROOT_DIR=/opt/telorb

  # CrashCollector's dir
  CRASHCOLLECTOR_DIR=/opt/telorb/crashcollector

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Verification of Crash Collector
 (Updated: 2003-12-15)

To verify the Crash Collector do as follows:

Since epct files below directory /opt/telorb/system/ will be crashcollected,
this should be verified.
In the instructions below, it is important that the file names end with ".epct",
since only these files in the directory /opt/telorb/system/ will be
crashcollected.

Copy any epct file (or create a fake epct file where the contents of the file
is not important) to both IO processors below directory
"/opt/telorb/system/".
Rename the epct files to e.g. crashcollectortest1_io1.epct and
crashcollectortest1_io2.epct on IO1 and IO2, respectively:
  mv <original_file_name> crashcollector_io1_test1.epct          (On IO1)
  mv <original_file_name> crashcollector_io2_test1.epct          (On IO2)

Copy the files, so that you get one more epct file on each of the IO processors:
  cp crashcollector_io1_test1.epct crashcollector_io1_test2.epct  (On IO1)
  cp crashcollector_io2_test1.epct crashcollector_io2_test2.epct  (On IO2)

Kill processes in the TelORB system which results in the following dumps, or
use test programs to generate the dumps (not necessarily all dumps in one go):
- DicosCapsuleTextDump
  (e.g. kill id of DdbomBackupSupervisor)
- DicosJavaDump
- DicosProcessorTextDump
  (e.g. kill id of DDB Configuration Manager Agent)
- DicosSyslog

For instructions on how to kill processes on Dicos processors, see
Dicos error dumps, subsection "Creating error dumps for testing purposes".

In order to get Linux core dumps, see instructions on how to kill processes on
Linux processors, at Linux error dumps, subsection
"Creating error dumps for testing purposes".

Verify that a file with the name crashcollectorDATETIME.tar.Z is created in
directory "/opt/telorb/crashcollector/" for each of the dumps within 5 minutes
from when a dump was created (normally one file per dump).

The crash collector files should exist on both IO processors.
(However, in R14 the dumps for DicosProcessorTextDump and DicosSyslog will only
appear on one of the IO processors.) Unpack the crash collector file with
"tar xzvf crashcollectorDATETIME.tar.Z".

Depending on which processes that are killed, the system may behave in different
ways, but the impact on the system should be minimal, except for a TelORB
processor reload.

To get information about which files that should be collected by the Crash Collector when a crash occurs, see subsection "Files for collection" above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Crash Collector Implementation Proposal
 (Updated: 2001-05-07)

The following information is taken from the Crash Collector Implementation
Proposal as of 2001-05-07:

The changes include:

1.  Detail added to At detection of crash.
2.  In case of multiple dumps being collected for a crash, the date
    and time of last dump file is taken for naming.
3.  All epct files will be collected.
4.  File telorb.conf will be collected instead of file start_services.
5.  Logs for all processors will be collected.
6.  Remove Crash Collector archives older than a given number of days.

The daemon will run on both IOs. There is one remaining issue to be
resolved which is to do with the synchronization between the two
daemons running on different IOs when it comes to running services_list
script.


At startup:

* Check for and create the directory /export/home/telorb/crashcollector/,
  if necessary.
* Go into scanning.


Scanning - The daemon is constantly in sleep mode. Every 5 minutes it
wakes to scan the dumps directory:

* List /opt/telorb/dumps/ directory.
* Detect crash - Detect if any new dumps have been generated, within
  the last 5.5 minutes.
* Look for old (age configurable, default 30 days) Crash Collector
  files in /export/home/telorb/crashcollector/ directory.
* Sleep 5 minutes.


At detection of crash - If several dumps are found with times within
minutes of each other they will be considered as unrelated and packed
as separate crashes. If several dumps are found with times within
seconds of each other they will be considered part of the same problem
and packed together. When a crash is detected, ie. when at least one
dump is found, the following is performed:

* Create /export/home/telorb/crashcollector/temp/ directory.
* Run services_list in /opt/telorb/etc/ directory on IO1 to create
  services_list_io1.out in /tmp/crashcollector/ directory.
* Run services_list in /opt/telorb/etc/ directory on IO2 to create
  services_list_io2.out in /tmp/crashcollector/ directory.
* Create list of files for collection.
* Copy files to /export/home/telorb/crashcollector/temp/ directory.
* Archive the files with filename crashcollectorDATETIME.gtar and
  store in /export/home/telorb/crashcollector/ directory. The date
  and time are of the creation of the TextDump file.
  In case of multiple dumps the date and time will be of latest file.
* Tidy up by removing /export/home/telorb/crashcollector/temp/
  directory.
* If archiving was successful delete the TextDump files.
* Go back to scanning.

Create list of files for collection:

* For crash on IO1.
* Files in /opt/telorb/dumps/ directory on IO1.
* All files logXX and logXX.b in /opt/telorb/consolelogs/ directory
  on IO1.
* All epct files in /opt/telorb/system/ directory on IO1.
* File telorb.conf in /opt/telorb/etc/ directory on IO1 as
  telorb.conf.io1 .
* File services_list_io1.out and services_list_io2.out in
  /opt/telorb/etc/ directory on IO1 and IO2 respectively.
* File kernelConfigurationDataLm in
  /opt/telorb/axe/loadingGroup/ProcessorXX/processorConfiguration/
  directory on IO1 (or IO2).
* For crash on IO2.
* Files in /opt/telorb/dumps/ directory on IO2.
* All files logXX and logXX.b in /opt/telorb/consolelogs/
  directory on IO1.
* All epct files in /opt/telorb/system/ directory on IO1.
* File telorb.conf in /opt/telorb/etc/ directory on IO2 as
  telorb.conf.io2 .
* File services_list_io1.out and services_list_io2.out in
  /opt/telorb/etc/ directory on IO1 and IO2 respectively.
* File kernelConfigurationDataLm in
  /opt/telorb/axe/loadingGroup/ProcessorXX/processorConfiguration/
  directory on IO2 (or IO1).

Adjust xx to valid network address in the URLs below:

http://134.138.xx.101:5557/         (TelORB processor 1)
http://134.138.xx.102:5558/         (TelORB processor 2)
http://134.138.xx.103:5559/         (TelORB processor 3)
http://134.138.xx.104:5560/         (TelORB processor 4)
http://134.138.xx.105:5561/         (TelORB processor 5)
http://134.138.xx.106:5562/         (TelORB processor 6)
http://134.138.xx.107:5563/         (TelORB processor 7)
http://134.138.xx.108:5564/         (TelORB processor 8)
http://134.138.xx.109:5565/         (TelORB processor 9)
http://134.138.xx.110:5566/         (TelORB processor 10)
http://134.138.xx.111:5567/         (TelORB processor 11)
http://134.138.xx.112:5568/         (TelORB processor 12)
http://134.138.xx.113:5569/         (TelORB processor 13)
http://134.138.xx.114:5570/         (TelORB processor 14)
http://134.138.xx.115:5571/         (TelORB processor 15)
http://134.138.xx.116:5572/         (TelORB processor 16)
http://134.138.xx.117:5573/         (TelORB processor 17)
http://134.138.xx.118:5574/         (TelORB processor 18)
http://134.138.xx.119:5575/         (TelORB processor 19)
http://134.138.xx.120:5576/         (TelORB processor 20)
http://134.138.xx.121:5577/         (TelORB processor 21)
http://134.138.xx.122:5578/         (TelORB processor 22)
http://134.138.xx.123:5579/         (TelORB processor 23)
http://134.138.xx.124:5580/         (TelORB processor 24)
http://134.138.xx.125:5581/         (TelORB processor 25)
http://134.138.xx.126:5582/         (TelORB processor 26)
http://134.138.xx.127:5583/         (TelORB processor 27)
http://134.138.xx.128:5584/         (TelORB processor 28)
http://134.138.xx.129:5585/         (TelORB processor 29)
http://134.138.xx.130:5586/         (TelORB processor 30)

Example:
Check which TelORB processor that hosts the Configuration Manager (CM):
http://134.138.xx.101:5557/SWS/CM

Hints
-----
- If it is not possible to access a TelORB processor via the WWW interface (it
  is probably not possible to telnet it directly either), it might be worthwhile
  to check if the TelORB processor can be accessed via one of the IO processors
  that is located in the same TelORB zone.
  From a local shell (Pink LAN):
    telnet toXio1                         (Log in to IO processor 1 or 2. Adjust
                                           toX to valid TelORB system or use IP
                                           address)
    login: telorb                         (Type user name)
    Password:                             (Type password)

    telnet 134.138.xx.101 8000            (Log in to e.g. TelORB processor 1)
                                          (Adjust xx to valid network address)
      or

    telnet 134.138.xx.104 8003            (Log in to e.g. TelORB processor 4)
                                          (Adjust xx to valid network address)

  For further instructions, see Read and set environment data in a live system.

General
 (Updated: 2003-01-31)

Log in to a TelORB processor with Dicos OS from one of the IO processors:
  telnet 172.16.xx.yy 80zz            (Adjust xx and yy to get valid IP address)
                                      (Adjust zz to valid TelORB
                                       processor using the TP index value)
    -or-
  telnet Proc_mM_sS 80zz              (Adjust M to valid Magazine and S to
                                       valid Slot)
                                      (Adjust zz to valid TelORB processor
                                       using the TP index value)

  $ /> cd SWS  (or use the web interface from one of the IOs:
                   http://172.16.16.7:5559/SWS/PSM (adjust IP address and port))
  $ /SWS> cat CM
    Example of printout:
      CM master located on processor: 1.4 
      Current CM state is: 4 (see DswcmConfigurationManagerControl.hh) 
      Software version is: backups/to28_r14lp6_2nd_uablrekdemoapp_traf_noviptraf

      CMAD (see DswcmCmCmaInterface.hh): 
      Waiting for message(s): 16 17 

      Other (outstanding) asynchronous messages  (see DswcmConfigurationManagerControl.hh):  
    End of printout

    From the printout example, one can see that the CM is located in TelORB
    processor Proc_m0_s9 (1.4) (May be a different processor) and that the CM
    state is idle (4).

  $ /SWS> cat PSM  (or use the web interface from one of the IOs:
                   http://172.16.16.7:5559/SWS/PSM (adjust IP address and port))
    Example of printout:
      PSM states   (see DswcmDcpListItem.hh): 
        DCP 1.4:       OpState: 3      LoaderState: 1  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.1:       OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.2:       OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.3:       OpState: 3      LoaderState: 0  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.5:       OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.6:       OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.7:       OpState: 3      LoaderState: 0  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.8:       OpState: 3      LoaderState: 0  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.9:       OpState: 3      LoaderState: 0  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.10:      OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.11:      OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.12:      OpState: 3      LoaderState: 2  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.13:      OpState: 3      LoaderState: 0  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.14:      OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.15:      OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.16:      OpState: 3      LoaderState: 0  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.17:      OpState: 3      LoaderState: 0  scheduledForHwReconfiguration: 0        Mngmt-state: 3 
        DCP 1.18:      OpState: 3      LoaderState: 3  scheduledForHwReconfiguration: 0
    End of printout

    Legend
    ------
    "DCP 1.2:"       = Dicos Control Processor 2.
    "OpState: 2"     = Processor not connected according to CM.
    "OpState: 3"     = Processor connected according to CM.
    "LoaderState: 0" = Non-loader (Non-PLGL).
    "LoaderState: 1" = Standby loader (Standby PLGL) (Decided at system startup,
                       can only be changed if the processor is disabled).
    "LoaderState: 2" = Primary loader (Primary PLGL) (Decided at system startup,
                       can only be changed if the processor is disabled).
    "LoaderState: 3" = Self-loader (Non-PLGL) (e.g. Linux processor).

To quit, enter quit.

Hints for early TelORB R14 (early JAP 3.0) and even earlier releases

Log in to a TelORB processor from a shell:
  telnet 134.138.xx.yyy 8000              (Adjust xx and yyy to valid network
                                           address and TelORB processor address)
                                          (Adjust 8000 to valid TelORB
                                           processor using the TP index value)
  $ /SWS> cat CM
    Example of printout:
      CM master located on processor: 1.2 
      Current CM state is: 4 (see DswcmConfigurationManagerControl.hh) 
      Software version is: backups/to28_R14p6_drop2.1_traf 

      CMAD (see DswcmCmCmaInterface.hh): 
      Waiting for message(s): 16 

      Other (outstanding) asynchronous messages  (see DswcmConfigurationManagerControl.hh): 
    End of printout

    From the printout example, one can see that the CM is located in TelORB
    processor 2 (1.2) and that the CM state is idle (4).

-  -  -  -  -  -  -  -  -  -  -  -

An example of when the CM is waiting for processor 8 to answer:
  $ /> cat SWS/CM
  CM master located on processor: 1.1 
  Current CM state is: 41 (see DswcmConfigurationManagerControl.hh) 
  Software version is: backups/to28_drop2.1_javaTraf 

  CMAD (see DswcmCmCmaInterface.hh): 
  Waiting for message(s): 16 

  Waiting for message(s): 1 
  From DCP(s): 1.8 

  Other (outstanding) asynchronous messages  (see DswcmConfigurationManagerControl.hh):


"CM - CMA - DUG - application process" relationships

|----|    |-----|    |-----|    |---------------------|
| CM |----| CMA |----| DUG |----| Application process |
|----|    |-----|    |-----|    |---------------------|

CM located in both loaders (one master and one redundant).
  Supervises all CMAs in all processors.

CMA located in all processors (also in loaders).
  Supervises all DUGs in own processor.

DUG located in all processors.
  Supervises supervised application process(es) in own processor.

If an application process is killed, its supervising DUG will start it again.
If the DUG is killed, the CMA in that processor will start it again.
If the CMA is killed, the processor will reload.

It is possible to read and set/change environment data in a live system.
Environment data is the data that is specified in the epct file(s) within the
tags ENVIRONMENT DATA and ENDDATA.
To read e.g. environment data using the WWW interface, see
Read info from TelORB processors via WWW.

Log in to any of the TelORB processors by using telnet:
    telnet Proc_m0_s9 8002               (Log in to e.g. TelORB processor
                                           Proc_m0_s9 from IO)
                                         (Valid for TelORB R15 Clusterware & OS)

      -or-

    telnet 172.16.xx.yyy 80zz            (Log in to a TelORB processor from IO)
                                         (Valid for TelORB R14 Clusterware & OS)

      -or-

    telnet 134.138.xx.101 8000            (Log in to e.g. TelORB processor 1)
                                          (Adjust xx to valid network address)
                                          (Valid for older releases)
      -or-

    telnet 134.138.xx.104 8003            (Log in to e.g. TelORB processor 4)
                                          (Adjust xx to valid network address)
                                          (Valid for older releases)

If this is not possible, the TelORB processors can be accessed via one of the
IO processors which are located in the same TelORB zone. Log in to one of the
IO processors by using telnet and thereafter telnet in to the desired TelORB
processor.

- When reading and setting environment data, it does not matter which TelORB
  processor that is logged in to (any TelORB processor will do). When setting
  environment data, this only has to be performed in one TelORB processor.

- Read environment data (example for TelORB R14 Clusterware & OS):
    $ /> cd env
    $ /env> printenv
    RSAllowedDelay = 60000
    RSMessageSize = 65408
    DdbLazyPurgeInterval = 60000
    GESB0 = GESB_A,2,23,4
    RSCompensationDelay = 120000
    RSPriority = NormalPriority
    GEM_SCB_FANUNITS = 1,0,1,0,1,0,1,0
    RSMaxMissingAcks = 1
    GEM_SCB_ADDRESSES = SCB_0A,SCB_0B,SCB_1A,SCB_1B,SCB_2A,SCB_2B,SCB_3A,SCB_3B
    RSLimit = 30000
    RSSendPolicy = 1
    GESB1 = GESB_B,3,23,4
    AlarmPanelAddress = 172.18.101.101, 172.19.101.101, 172.18.102.101, 172.19.102.101
    PpClientTimeout = 1000
    GEM_HWI_ENABLED = 1

- Read environment data (example valid for earlier releases):
    $ /> cd env
    $ /env> printenv
    ETHSW_ADDRESSES = 134.138.57.20,134.138.58.20,134.138.57.21,134.138.58.21
    RSAllowedDelay = 60000
    ETHSW_POLL_INTERVAL = 15000
    ETHSW_CFG_INTERVAL = 1800000
    RSMissingAcks = 100
    RSCompensationDelay = 120000
    RSPriority = NormalPriority
    SampleFailingMirror = 0
    RSLimit = 30000

- Read environment data in R13p5 (RS-data for 100 Mbit/s):
    $ /> cd env
    $ /env> printenv
    AXMP_ADDRESSES = to10s7c1:9977,to10s7c2:9977
    RSLimit = 30000
    RSMaxMissingAcks = 1
    AXMP_VOLTAGE_INTERVAL = 24-33
    AXMP_POLL_INTERVAL = 20000
    RSMissingAcks = 100
    RSCompensationDelay = 120000
    ETHSW_POLL_INTERVAL = 15000
    ETHSW_CFG_INTERVAL = 1800000
    ETHSW_ADDRESSES = 134.138.61.20,134.138.62.20,134.138.61.21,134.138.62.21
    RSAllowedDelay = 360000
    RSPriority = NormalPriority
    RSSendPolicy = 1
    PpClientTimeout = 1000
    AXMP_HIGH_TEMP = 50
    RSMessageSize = 65408

- Set and unset environment data:
    $ /> cd env
    $ /env> setenv RSLimit 20000
    $ /env> unsetenv RSLimit

  Once e.g. the environment variable RSLimit is set by using setenv, its value
  gets set immediately in the database. Then it is up to the Application to read
  the value for the new value to really take effect.
  
- Quit and exit:
    quit
    exit

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
 (Updated: 2003-10-08)
If you want to perform some settings when reloading a system, e.g.
export TSP_REBOOT="NO", just implement the string in a file called
tsp.conf and place it below /opt/telorb/axe/loadingGroup01_n.
A tsp.conf file may look as follows: 
  export TSP_REBOOT="NO"
  klogconsole -l 7 -r /dev/console

General
 (Updated: 2003-01-31)

Log in to a TelORB processor with Dicos OS from one of the IO processors:
  telnet 172.16.xx.yy 80zz            (Adjust xx and yy to get valid IP address)
                                      (Adjust zz to valid TelORB
                                       processor using the TP index value)
                                      (E.g. telnet 172.16.0.9 8002)
    -or-
  telnet Proc_mM_sS 80zz              (Adjust M to valid Magazine and S to
                                       valid Slot)
                                      (Adjust zz to valid TelORB
                                       processor using the TP index value)
                                      (E.g. telnet Proc_m0_s9 8002)

  $ /> cd CLI
  $ /CLI> ls 
  AlarmsAndNotifications/
  Backups/
  DiskLog/
  DNS/
  Hardware/
  History/
  Inventory/
  NetRed/
  Network/
  NFS/
  Processors/
  SysLog/
  Time/
  Upgrades/
  VIP/
  getinfo*

  $ /CLI> cd Processors/

  $ /CLI/Processors> ls
  disable*
  enable*
  getprocessorinfo*
  listdus*
  listlms*
  listpools*
  listswitches*
  listprocessors*
  moveallDUs*
  reload*
  resetswitch*
  setDBNmemoryalarmlevel*
  setDBNmemoryshare*
  setloadregulationlevel*
  setmemoryalarmlevel*
  supplywithDUs*
  zonereload*

To e.g. enable TelORB processor Proc_m0_s23, enter the following command:
  $ /CLI/Processors> enable Proc_m0_s23

To quit, enter quit.


Example of CLI usage: Activate an old backup and perform a zone reload
----------------------------------------------------------------------
$ /> cd CLI/Backups/

$ /CLI/Backups> list
--- Backups ---
Upgrade_step1_2005-09-30_10:33:26_final
Upgrade_step2_2005-09-30_11:37:12_final
to14_1st_rm453mcp3_noNetRed_noTraffic
to14_4th_after_step3_notraffic
Upgrade_step4_2005-10-03_17:04:16_temp
Proc4__2005-10-03_17:08:06
Proc5__2005-10-03_17:12:01
(A)Upgrade_step4_2005-10-03_16:59:21_final
-----------------
###### SCHEDULER ######
Scheduler is: Enabled
--- Periodic Scheduling ---
No periodic scheduling done
Number of periodic backups kept:3
-------------------------
--- Scheduled Fixeds: ---
Number of fixed backups kept:3
-------------------------
No backups/remote synchs scheduled

$ /CLI/Backups> activate to14_4th_after_step3_notraffic

Backup has been activated

$ /CLI/Backups> list
--- Backups ---
Upgrade_step1_2005-09-30_10:33:26_final
Upgrade_step2_2005-09-30_11:37:12_final
to14_1st_rm453mcp3_noNetRed_noTraffic
(A)to14_4th_after_step3_notraffic
Upgrade_step4_2005-10-03_17:04:16_temp
Proc4__2005-10-03_17:08:06
Proc5__2005-10-03_17:12:01
Upgrade_step4_2005-10-03_16:59:21_final
-----------------
###### SCHEDULER ######
Scheduler is: Enabled
--- Periodic Scheduling ---
No periodic scheduling done
Number of periodic backups kept:3
-------------------------
--- Scheduled Fixeds: ---
Number of fixed backups kept:3
-------------------------
No backups/remote synchs scheduled

$ /CLI/Backups> cd ../..

$ /> CLI/Processors/zonereload 
Are you sure you want to order a Zone Reload?
If this is a live system, you should
contact your local support centre first.
Confirm action (by typing ";"): ;
Command failed - CORBA System Exception - commFailure exception


Example of CLI usage in TSP 5 (only valid for Dicos processors)
---------------------------------------------------------------
The example is valid for correcting the VIP configuration on the Dicos
processors after initial installation of TSP 5.0 LSV509A.
From IO2:
  telnet localhost 8000
  cd /CLI/VIP
  listdevices
  removegateway i4dd0 Proc_m<m>_s<s> <if> <gw>
  addgateway i4dd0 Proc_m<m>_s<s> <if> <gw>
  exit

Assertion failure = ~jump to illegalstate.

Explanation to the following DicosTextDump:

   "Processor: [1.1.1]
    Capsule abortion no 1
    CapsuleId: 2345949
    CapsuleName: <DUG-999818>
    Reason: Assertion "0" failed at DeedugCentral.cci:153 [SCC/AXG73 R1J03]
      :"

The Distribution Unit Group (DUG)(SCC/AXG73), that starts and stops processes,
has sent `takeover' to the process 999818, but the process 999818 does not
send ready to the DUG. In this case, the DUG performs an assertion failure.

To find out which process that does not answer with `ready', in this case
999818, do the following after remote log in to IO processor 1 (or IO2):

  cd /opt/telorb/axe/loadingGroup01_1/initialData/
  less earlyBaseConfigurationDataLm
  /999818                (Find line containing 999818)
  q                      (Quit less-mode)

To find out where in the DUG-code the assertion failure happens, do the
following, preferably from where the TelORB system was built (tos1/tos2):

  source Envsettings     (If not already entered)
  source /ipims_dicos/BS2/dicostb38.6/IP_CONF_INFO/EnvSettings.linux
                         (Use the testbed that corresponds to the AD that is
                          used in the TelORB system)
  epgetpath SCC/AXG73    (Get the path to where the code is located, e.g.
                          /ipims_dicos/ipims_dicos20/BS2/dicostb38.6/
                          DICOS_SA/ExecutionEnvironment_SE/
                          ProcessDistribution_SWCLib/Distribution_SCC)
  cd /ipims_dicos/ipims_dicos20/BS2/dicostb38.6/DICOS_SA/ExecutionEnvironment_SE/ProcessDistribution_SWCLib/Distribution_SCC
                         (Go towards the location of the code)
  cd src                 (Go to the location of the code)
  ls -l                  (Check that, in this case, Deedug.cc exists)
  less -N DeedugCentral.cci (Check which line number in the DUG where the
                             assertion fails ... or use the VI texteditor)
  q                      (Quit less-mode)

You may also search for the "DUG" in the config file (e.g. to15.config) below
/opt/telorb/axe/loadingGroup01_1/ on any of the IOs.

Commands
Why do the TelORB ep-commands begin with the letters 'ep'?

		Some of the TelORB "tools", e.g. epct, epbuild and
		epconfig, begin with the letters 'ep'. This is because
		the day the TelORB project started (AXE-N) the name of		
		the day ("namnsdag" in Swedish) was 'Elof' (June 30)
		which begins with an 'e'. Since nobody could come up
		with a good name for the current project, the name of
		the day, Elof, was used as part of the project name,
                i.e. the project was named the "Elof project" (ep).

epct		The epct command is used to initially configure a TelORB system
		with respect to the relationship between software and processing
		hardware, as well as upgrading the configuration with new
		software.
		epct takes a description of the desired configuration and
		produces a file tree with the files necessary to start or
		upgrade the system. The description has a number of
		specification elements:
		o	The name of the configuration.
		o	The software that is to be run in the system expressed
			as the identities of a number of Internal Delivery
			Packages, IDPs.
		o	The processor pools that the software should be
			allocated to.
		o	Specifications of how the software, in terms of
			Distribution Unit  DUTs, is allocated to the pools.
		o	The processors in the system and their assignments to
			processor pools.
		o	Data to the system.

		The description is typically divided into target system
		independent parts, and a target system dependent part.
		The former are done in files called config.epct that are written
		per IDP and contain specifications of the processor pools needed
		for each IDP, and the allocation of all DUTs in the IDP to these
		pool. These files should not refer to anything outside the IDPs
		themselves.
		The latter, target system dependent part, can be one or more
		files specifying the name of the configuration, a number of IDPs
		and the processors in the target system and how these are
		connected to the processor pools.
		When upgrading the software in a system, the same description
		(unless modified when adding or removing IDPs) is given, but
		also a reference to a file describing the current system
		configuration that was produced by epct the last time it was
		run.

		The epct command is the last command entered before booting a
		target TelORB system, or starting Vega with eprun.
		Type `epct -h' for more info.

epbuild		The epbuild command builds Delos, C++ code, Java code,
		and loadmodules.
		Type `epbuild -h' for more info.

epconfig	The epconfig command connects all eptools to the path of the
		code which is being implemented. The epconfig command has to be
		entered to be able to get the rest of the eptools working.
		If the rest of the eptools can find SWIs, OUs and LMs, the
		epconfig command is working.
		Type `epconfig -h' for more info.


epcoredbg       Per Karlsson has added command "epcoredbg" in tblp8 to produce a
                backtrace from Linux core files.

                  Usage: epcoredbg [-h] [-g] [-f program] core
                         -h     print this text
                         -g     start inteactive gdb session
                         -f     debug program, default is lmstarter
                         core   the core file

                The running program is assumed to be lmstarter (which is true
                for all delos specified processes).
                The program uses gdb which means that it will only work on
                Linux.
                Comments or TRs to Per Karlsson.
                (Updated 2003-06-12)

epelfaddr	The epelfaddr command converts a hexadecimal TelORB processor
		error dump to the corresponding source code.
		Type `epelfaddr -h' for more info.

eprun		The eprun command is used to start up a Vega system.

epgetattr       E.g. "epgetattr basicname CXP/901441/1" (or IDP identity)
                gives "TelorbLinuxJava".
                Before entering the epgetattr command, the valid testbed has to
                be sourced, e.g. for TSP 5.0:
                  source /ipims_dicos/ipims_dicos20/BS2/tbAD15/IP_CONF_INFO/EnvSettings

epgetpath	The epgetpath command takes the identity of an MI as an input
		and returns its path.
		E.g. `epgetpath LM/MD43' gives:
		/ipims_dicos/ipims_dicos10/dists/TelORB-AD4.12/system/runtime/IDP_MD15-Unix/LM_MD43-Ldu

epfollow	(Type `epfollow -h' for more info)
		E.g. get info about which OUs that belong to an LM, e.g.:
			epfollow LM/AXG695
			LM/AXG695    -> OU/AXG2263
			OU/AXG2263   -> SWI/AXG3027
			OU/AXG2263   -> SWI/AXG2444
			SWI/AXG2444  -> SWI/AXG3026
			SWI/AXG3026  -> SCC/AXG377
			OU/AXG2263   -> SWI/AXG2922
			SWI/AXG2922  -> SCC/AXG435
			SCC/AXG435   -> SWI/AXG1720
			SCC/AXG435   -> SWI/AXG1721
			OU/AXG2263   -> SWI/AXG702
			SWI/AXG702   -> SCC/AXG56

epuses		The epuses command takes the identity of an MI as an input and
		returns the identity of LMs of which the input file ...

epdeps		The epdeps command returns the dependencies of a specified
		identity (or a list of identities).
		(Type `epdeps' for more info)
		E.g. get info about which LM that belongs to an OU, e.g.:
		epdeps OU/AXG2263
			LM/AXG695

			(One OU can be used by several LMs.)

epprofan        Support script to the profiling tool.
                See U-Qtil (Utilities) for further info.

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

epapiref

                Just wanted to promote the command 'epapiref' which provides an
                easy access to our API reference documentation.
                'epapiref' starts a netscape through which you can browse the
                documentation.

                For our main C++ and Java APIs, type:

                  %  epapiref CXA/1100926/1


                For our IDL specs, type:

                  %  epapiref CXA/1100928/1


                The API documentation as such is according to me reasonably
                complete and accurate, so don't hesitate to use it.

Source: E-mail from Stefan Näslund, 2004-01-12. TSP R15.

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

epsi		(Version handling utility program for TelORB)

  - Get epsi help:
      epsi
    or
      epsi -h

  - Checkout the latest LM and OU from the repository:
      epsi co LM/AXG673
      epsi co OU/AXG673

  - Check which LM versions that can be checked out from the repository:
      Either
        epsi tree -m LM/AXG673
      or when standing on e.g.
      /home/telorb/users/uabxxx/backdoor/ConfigManagerAgent_LM/
      after the LM has been checked out by e.g. epsi co LM/AXG673
        epsi tree

  - Checkout an LM after checking which LM versions that can be checked out
    above (only branch tag marked LMs can be checked out):
      epsi co -r R13 LM/AXG673

  - Checkout an LM with a special version without being able to check it in
    again:
      epsiadm export -r R1H01 LM/AXG673

  - Example of epsi printouts:
         epsi co LM/AXG673                  (Checkout latest LM) (co = checkout)
         ( Example of printout:
           cvs co  LM/AXG673_R
           cvs checkout: Updating ConfigManagerAgent_LM
           U ConfigManagerAgent_LM/.MI_checksum
           U ConfigManagerAgent_LM/MI_attributes )

        epsi co OU/AXG2157                  (Checkout latest LM) (co = checkout)
         ( Example of printout:
           cvs co  OU/AXG2157_R
           cvs checkout: Updating ConfigManagerAgent_OU
           cvs checkout: Updating ConfigManagerAgent_OU/cert
           cvs checkout: Updating ConfigManagerAgent_OU/doc
           cvs checkout: Updating ConfigManagerAgent_OU/src
           U ConfigManagerAgent_OU/.MI_checksum
           U ConfigManagerAgent_OU/Imakefile
           U ConfigManagerAgent_OU/MI_attributes
           U ConfigManagerAgent_OU/README
           U ConfigManagerAgent_OU/src/DswcmaCentralDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaCentralDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaCmSetupSupervisor.cc
           U ConfigManagerAgent_OU/src/DswcmaCmSetupSupervisor.hh
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.cc
           U ConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.hh
           UConfigManagerAgent_OU/src/DswcmaConfigurationManagerAgentControl.icc
           U ConfigManagerAgent_OU/src/DswcmaConstants.hh
           U ConfigManagerAgent_OU/src/DswcmaDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaDistributionPort.cc
           U ConfigManagerAgent_OU/src/DswcmaDistributionPort.hh
           U ConfigManagerAgent_OU/src/DswcmaDynamicKeyedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDynamicKeyedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaDynamicReplicatedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaDynamicReplicatedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaInstallationPort.cc
           U ConfigManagerAgent_OU/src/DswcmaInstallationPort.hh
           U ConfigManagerAgent_OU/src/DswcmaInstalledDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaInstalledDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaLoadingManager.cc
           U ConfigManagerAgent_OU/src/DswcmaLoadingManager.hh
           U ConfigManagerAgent_OU/src/DswcmaProcessData.cc
           U ConfigManagerAgent_OU/src/DswcmaProcessData.hh
           U ConfigManagerAgent_OU/src/DswcmaProcessManager.cc
           U ConfigManagerAgent_OU/src/DswcmaProcessManager.hh
           U ConfigManagerAgent_OU/src/DswcmaReplicatedDUG.cc
           U ConfigManagerAgent_OU/src/DswcmaReplicatedDUG.hh
           U ConfigManagerAgent_OU/src/DswcmaStarter.cc )

- Check when an LM was checked in and by whom:
    epsi who LM/MD39 `epgetattr Version LM/MD39`

      cvs ci at; date: 2004/02/05 11:20:20;  author: uablrek;  
          Checked in with epsi by uablrek

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

epvc		Replaces the epsi command in TSP 5.

  - Check version of e.g. the operating system CXP on IO processors:
      source /ipims_dicos/BS2/tbWP139/Setup.csh
      epvc tree -m CXP9010596/1

  - Checkout the IO CXP after checking which CXP versions that can be checked
    out above:
      epvc co -r R50FY01 CXP9010596/1

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

epsiadm		(Administrative help routines for TelORB to e.g.
		export LMs and/or OUs from the repository)

  - Get epsiadm help:
      epsiadm
    or
      epsiadm -h

  - Note that after an LM and/or OU have/has been exported, it cannot be
    checked in to the repository. For this purpose, use the epsi command to
    checkout and checkin.

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

lduReverse

E.g. from tos1/tos2:
lduReverse /ipims_dicos/ipims_dicos10/dists/TSP4.0/Drop2.1/IDP_MD14-Dicos/included/LM_AXG561-DicosKernel/bin/DicosKernel.LM_AXG561.Code.R1N.i486

Also used to check the bootLoadTable.0 for a processor on the IO processor, e.g.
  lduReverse /opt/telorb/axe/loadingGroup01_X/ProcessorY/bootLoadTable.0
If lduReverse results in the response "Command not found" on e.g. an IO
processor, use tos1/tos2, e.g.:
  lduReverse /to21/to21io2/telorb/axe/loadingGroup01_2/Processor1/bootLoadTable.0

If there is no bin directory below
/opt/telorb/codearchive/Unix_IDP/included/LM_MD42-LduReverse/
on the IO processors, it is not possible to execute lduReverse.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Alias to make it possible to see the MI_attributes file of an OU (or SWI, or LM, etc)
 
alias epmi 'more `epgetpath \!*`/MI_attributes'

So you can type
  epmi OU/AX567

and you will directly see the MI_attributes file of that OU (or SWI or LM, etc)
without having to copy and paste huge paths.

You can, of course, adapt the alias to do whatever you want (and name it what
you want).

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Scripts
difind

The "difind"-command is used to find a certain source code file. 

Source a testbed to be able to enjoy "difind", e.g.
  source /ipims_dicos/ipims_dicos20/BS2/tbAD15.7/IP_CONF_INFO/EnvSettings

Example: 
  difind DicosPort.hh
    SWI/AXG670 /ipims_dicos/ipims_dicos20/BS2/tbAD15/DXPI_SWILib/ExecutionEnvironment_SWILib/Port_SWI/incl/DicosPort.hh

Note: The "difind"-command is available from tb38.4 and onwards.

(Source: E-mail from Stefan Näslund, 1999-02-09. Modified by Michel)


Repeat ping

The following script pings the EAB CW/OS lab lab router and some of its
ports, as well as the ethernet switches for to6:

#!/bin/ksh
dummy=0

while [ $dummy -lt 1 ]
do

sleep 2
date
echo "/usr/sbin/ping 134.138.17.2"
/usr/sbin/ping 134.138.17.2

sleep 2
echo "/usr/sbin/ping 134.138.184.1"
/usr/sbin/ping 134.138.184.1

sleep 2
echo "/usr/sbin/ping 134.138.59.1"
/usr/sbin/ping 134.138.59.1

sleep 2
echo "/usr/sbin/ping 134.138.60.1"
/usr/sbin/ping 134.138.60.1

sleep 2
echo "/usr/sbin/ping 134.138.76.20"
/usr/sbin/ping 134.138.76.20

sleep 2
echo "/usr/sbin/ping 134.138.77.20"
/usr/sbin/ping 134.138.77.20

done

The script is called pingloop and is located at /home/telorb/ at to15io1.

To store the ping results in a log file, enter e.g. the command
./pingloop | tee pinglog
when standing on /home/telorb/. The printouts will end up in the log file
pinglog. Be sure to remove the log file after usage, since it may take up a
lot of memory.

General
 (Updated: 2004-01-28)

This is an example on how to build a debug version of DicosKernel.LM_AXG561 for
e.g. troubleshooting purposes.

Log in to e.g. tos2 as telorb:
  ssh telorb@tos2

Enter the following commands on tos2:
  cd to28                             (Adjust to28 to valid TelORB system)
  cd TelORB-R15-DicosOnly             (Adjust directory to valid directory.
                                       Any directory will actually do)
  mkdir dicosdebugkernel
  cd dicosdebugkernel/
  setenv EP_WORKSPACE `pwd`/epws
  source /ipims_dicos/ipims_dicos20/BS2/tbAD15LSV-505.3/IP_CONF_INFO/EnvSettings
  (Adjust path to valid testbed)
  source /ipims_dicos/ipims_dicos20/BS2/tbTEST15.0LSV-505.1/IP_CONF_INFO/EnvSettings
  (Adjust path to valid testbed for traffic application)
  epconfig s -r <other_valid_TLMs_if_any>
                                      (If DicosKernel is included among the
                                       valid TLMs, and you want to keep this
                                       TLM, this TLM should also be epconfig
                                       set here (to get the TLM changes also
                                       in the debug DicosKernel to be built))
  epconfig l -v
  epsi tree -m LM/AXG561              (DicosKernel)
  epsi co -r R3B07 LM/AXG561          (Check out valid DicosKernel)
  (epconfig l -va | grep Allocator_OU  (Get OU id for Allocator_OU))
  epsi tree -m OU/AXG1928             (Check which version of Allocator_OU to
                                       use)
  epsi co OU/AXG1928                  (If no version is specified, the last
                                       version listed in epsi tree will be used.
                                       To specify the version, enter e.g.
                                       `epsi co R1G06 OU/AXG1928')
  ls -l
  epconfig l -v                       (Verify all epconfig settings)
  epconfig s -r dicosdebugkernel/
  cd Allocator_OU/src
  ls -l
  emacs Deek_heap.cc &

    In the beginning of the file, change

      #define MM DeekMM

      #if 0

    to

      #define MM DeekMM

      #if 1
 
    Save and exit the file.

  less Deek_heap.cc                   (Verify the change)
  epbuild -T i486,i486-linux,i686,i686-linux,sparc,native OU/AXG1928
                                      (Build Allocator_OU for all targets)
  cd ..
  ls -l
  ls -l obj.i686-dicos
  cd ..
  ls -l
  cd DicosKernel_LM/
  ls -l
  emacs MI_attributes &               (Modify version, e.g. add "debug" to it)
  epbuild -T i486,i486-linux,i686,i686-linux,sparc,native LM/AXG561
                                      (Build DicosKernel for all targets)
  ls -l bin/                          (Verify that DicosKernel is built for all
                                       valid targets, not necessarily all
                                       targets that were specified in the
                                       epbuild command)

Build your system with an epconfig setting towards the newly built Dicos debug
kernel, e.g.
  epconfig s -r /home/dicostest/tosFiles/to28/TelORB-R15-DicosOnly/dicosdebugkernel/DicosKernel_LM/

U-Qtil
General

"U-Qtil" should actually be "Q-Util", but has been implemented incorrectly.

U-Qtil can only be used for Dicos processors.

In TSP 4 and higher, log in to a Dicos processor from one of the IO processors,
e.g.:
  telnet 172.16.0.9 8100

  (Using the old IP addressing scheme, the following IP address could be
   entered:
     telnet 134.138.xx.101 8100   (Log in to e.g. TelORB processor 1)
                                  (Adjust xx to valid network address))
U-Qtil> help
  cpuload -- get load per priority
  loadreg [ maxLoad [ basic-interval ] ] -- set load regulation parameters or get stats
  pp -- print ports
  tracep [-f] -- print trace
  tracei [-f] [-l] [-s size] expr ... -- init trace
  ms [-bhw] [-m mask] pattern start end -- search memory
  mx [-bhw] address [bytes] -- examine memory
  dump cid -- dump capsule
  kill cid ... -- kill capsules
  ts -- thread status
  ps -- process status
  cs -- capsule status
  heaplog -- print heap log
  heapstat -- get heap statistics
  mmus -- mmu stats
  fpus -- fpu stats
  smap -- print system memory map
  umap -- print user memory map
  help ...
  cat ...
  pwd ...
  cd ...
  ls ...

The help command is a bit crippled since it only lists commands below /bin.
For example, to get information about load modules, i.e.:
  "Relocating: DicosKernel.LM_AXG561.elf.R2C13.i486
   -----> code  at: 0x274d80 size: 0xc7010"
either enter
  U-Qtil> loadmodules/rellist
or
  U-Qtil> cd loadmodules
  U-Qtil> rellist
  U-Qtil> ls


cs                           (Check how much memory a process occupies,
                              e.g. JavaVirtualMachine)

quit                         (Quit telnet session)


Kill a process

telnet 172.16.16.9 8100      (Log in to e.g. TelORB processor Proc_m0_s9 in
                              zone 2)
  or
telnet 134.138.xx.114 8100   (Log in to e.g. TelORB processor 14)
                             (Adjust xx to valid network address)
ps                           (Check which processes that are running)
kill 504                     (Kill a process with e.g. process id 504)
                             (Adjust 504 to valid process identity)
                             (cid = capsule id)
quit                         (Quit telnet session)

Hints:   
For C and C++ code there is a one to one relationship between the capsule id and
the process id which makes it easy to kill a process.
However, for Java processes the situation is different. There is a capsule id
for the JVM (Java Virtual Machine) and all the Java processes on that processor
run within the JVM capsule.
To kill a Java process without killing the JVM capsule, kill the DUG (Distribution Unit Group) which belongs to the Java process, i.e. <DUG-rtid>. The DUG will in its turn kill its supervised application
process(es).
The DUG will then automatically be restarted by the CMA (Configuration Manager
Agent) and then the DUG will restart its supervised process(es).
(The hard part may be to find the `DUG-to-process' relationship out. To do this
you can use the userinfo for the related LM).


Check memory usage

telnet 134.138.xx.102 8100   (Log in to e.g. TelORB processor 2)
                             (Adjust xx to valid network address)
Trying 134.138.xx.102...
Connected to 134.138.xx.102.
Escape character is '^]'.
U-Qtil> smap
...
Free segments: 108 [108] ( => 108 4M pages = 432M free segments)
Free pages: 333 [333]    (Used 4M pages)
                         (512 M is the maximum amount of memory per TelORB
                          processor)


Check info for demo application (C++ and Java)

ps            (Check for DUG-1001781 (C++) or DUG-1001926 (Java) and use its PID in tracei below)
tracei -f C==135&&E==30=>L([&8,4])   ("C==135" = PID)
  or
tracei -f C==136&&E==30=>L(&3,[&8,4])


Time consuming threads

ts     (list threads) 
If e.g. ts shows a thread that is very time consuming, e.g.
    Id    Capsule  S P    Time     Type     Name
   2967        896 r 1 7857.254     524296 De2TGPT

Trace on everything related to the thread, e.g.
tracei -f T==2967=>L(E)      (Use capsule (process) id (PID))

If you want to kill the thread, kill its process (capsule), e.g.
kill 896

End trace:
tracei

Bonus:
ts 5211                                                     (JavaVirtualMachine)
       Id    Process  S P    Time   Name
     13406       5211 I 1    0.002 JavaVirtualMachine
     38093       5211 B 1    0.895 JavaVirtualMachine
     38602       5211 B 1  138.028 JavaVirtualMachine
     38643       5211 B 0   55.705 JavaVirtualMachine
     38647       5211 B 0   12.296 JavaVirtualMachine
     38863       5211 B 1    0.199 JavaVirtualMachine
     38864       5211 B 0   81.070 JavaVirtualMachine
     38868       5211 B 0    0.000 JavaVirtualMachine
     38870       5211 B 0    0.000 JavaVirtualMachine
     39382       5211 B 1    0.099 JavaVirtualMachine
     39392       5211 B 1    0.115 JavaVirtualMachine
     39413       5211 r 1 22371.353 JavaVirtualMachine


Trace

U-Qtil> trace/status
Trace not running

State 1:
	((E==9))=>L(T)

No breakpoints

No variables

U-Qtil> trace/breakpoint set 17 LM/MD47 R2A04 3381
U-Qtil> tracei -f E==9=>L(R0,R1,R2,R3,R4,R5,R6,R7,R8,R9)    
((E==9))=>L(R0,R1,R2,R3,R4,R5,R6,R7,R8,R9)
41281.608: R0=2684552192 R1=2684552204 R2=4025941232 R3=4025941216 R4=3705835312 R5=2684552204 R6=3705835312 R7=3705835272 R8=262791 R9=271165921
41281.617: R0=2684552192 R1=2684552204 R2=4025941232 R3=4025941216 R4=3705835312 R5=2684552204 R6=3705835312 R7=3705835272 R8=262791 R9=271165921
 :

U-Qtil> trace/breakpoint clear 17


Make tracei execute on the highest level (red)

Warning: This measure may be hazardous to your system. Do not perform this
         action in a live system!

!                            (The exclamation mark (!) must be entered directly
                              after you have entered U-Qtil, i.e. directly after
                              telnet)
                             (This supresses other activities)


Check memory usage in a TelORB processor

telnet 134.138.59.101 8100

U-Qtil> heapstat
=== MM:statistics ===
Range: 0x60000000 -- 0x8a6e1000
Counter: 698319098
138 segments free
6382771 segments used
6382941 segments total
1273808 octets free
204166206 octets used
205179585 octets ever used (peak)
711852032 octets total                   (No of available octets in memory)
=== done ===


Threads

U-Qtil> ls
trace/
threads/
capsules/
loadmodules/
bin/

cd threads/
ls

cat 4647                      (Use thread id)
    U-Qtil> cat 4647
    Addr:  @63F9A2E0
    Id:    4647
    Name:  (null)
    Type:  524296
    State: Ready
    Jobs:  14
    Context:     @638B0930
    Memory:      @64654178
    Current Job: @650289F8
    Job Queue:   @352FB4
    Blocker:     @0
    Resources:   @63AD0D80


Create a call chain

U-Qtil> threads/where 39413
Call chain: 0x1029a9e6 0x1029a8e0 0x1036b635 0x102ece3e 0x1042d73e 0x10030858 0x3b4fe4 0x3b93b1


Get LM data

U-Qtil> cat loadmodules/LM_MD47-R2A04
Identity:   LM/MD47
Version:    R2A04
Header cs:  504991772
Body cs:    331600769
Sections:
   .text     0x10297660 T 2077072
   .rodata   0x21764e80 C 341280
   .ctors    0x216fb4c0 C 212
   .dtors    0x216fb490 C 20
   .rodata.csþ÷© 0x216fb320 C 344
   .rodata.cU@ù©! 0x216fb300 C 8
   header    0x216fb2c0 C 36
   .data     0xc0000000 D 14152
   EUALPC    0x216fb2a0 D 8
   .bss      0xc0003780 B 48936


Profiler: Get info about what a processor is currently doing

Available from TSP R15.
Created by Hans Nordebäck and Lars Hennert.

This is e.g. useful if a processor is looping and e.g. has 100% load without
any traffic executing.

U-Qtil> cd profiler/

U-Qtil> ls
status*
stop*
start*

U-Qtil> status
Profiling not active

U-Qtil> start
Profiling started

U-Qtil> status
Profiling active, 145 traces collected (9 samples in buffer)
Profiling data file: /loadingGroup01_1/ProfilingData-Proc_m1_s19.dat
U-Qtil> status
Profiling active, 459 traces collected (279 samples in buffer)
Profiling data file: /loadingGroup01_1/ProfilingData-Proc_m1_s19.dat
U-Qtil> status
Profiling active, 838 traces collected (1126 samples in buffer)
Profiling data file: /loadingGroup01_1/ProfilingData-Proc_m1_s19.dat
U-Qtil> status
Profiling active, 1014 traces collected (81 samples in buffer)
Profiling data file: /loadingGroup01_1/ProfilingData-Proc_m1_s19.dat

         (Wait until ~1000 traces are collected)

U-Qtil> stop
Profiling stopped, 1057 samples collected in /loadingGroup01_1/ProfilingData-Proc_m1_s19.dat

Process the output file /loadingGroup01_1/ProfilingData-Proc_m1_s19.dat and view
its contents by using tos1/tos2:
  ssh telorb@tos1
  cd /home/dicoshack/Hack/telorb/
  ./epprofan-krni /to13/to13io1/telorb/axe/loadingGroup01_1/ProfilingData-Proc_m1_s19.dat > profiler_uabmsu01

  more /home/dicoshack/Hack/telorb/profiler_uabmsu01


Original e-mail from Lars Hennert, 2003-08-14:

As an experimental tool, I have delivered the profiling support developed
by Hans Nordebäck and myself to AD15.

The tool is useful for C++ code running on Dicos, and works by sampling
call chains to a file with regular intervals. The file can then be analyzed
offline with a script.

Since profiling is done only by sampling, the results are far from exact. For
better precision there are, or will be, tools from Rational, but these require
that the code is recompiled with special options while the sampling profiler
works on the code as is.


To start profiling, you telnet to Qtil (port 8100 or 42015 or whatever)
as usual, and give the command

        profiler/start

which stores data in /.../axe/loadingGroup01_1/ProfilingData-PROCESSORNAME.dat,
or

        profiler/start DIRNAME/FILENAME

which stores data in /.../axe/DIRNAME/FILENAME.

You can check the number of traces sampled so far with

        profiler/status

and finally stop profiling with

        profiler/stop

About 1000 traces are probably OK to start with; this takes about
two minutes on hardware since approximately 10 traces are sampled per
second (on Vega the number of traces per second are less deterministic).

To analyze the profiling data you run the epprofan script with the result
file's name as the argument

        epprofan /.../axe/DIRNAME/FILENAME

(The epprofan script is e.g. located at:
/ipims_dicos/ipims_dicos20/BS2/devenv4.0LSV-505/DevEnv_IDPG/DeploymentTools_IDP/DeploymentToolsLib_LM/scripts/epprofan  (Michel's comment))

Output goes to standard output so you might want to redirect to a file
or pipe through "less" or "more".

The output is divided into four sections:

PER FUNCTION -- gives the amount of time (in percent of total) spent in
different functions
ACCUMULATED -- the amount of time spent in different functions including
the time in called functions
BROKEN DOWN -- for each function how much time (in percent of that functions
total time) was spent in different called functions or itself
CALL CHAINS -- the entire call chain for each sampled trace

Here is an example from running a database intensive Java application:

--- PROFILING RESULTS ---
--- Data from /export/axe/loadingGroup01/ProfilingData-Processor1.dat
--- # traces = 1199


--- PER FUNCTION ---
 22.44%  UNKNOWN [(JIT or PROM)]
  3.00%  DeekCapsule_Local::launchJob(void *) [LM/AXG561]
  2.84%  Deeinp_blockingKernelCall [LM/AXG561]
  2.50%  BKC_InterruptEntry [LM/AXG561]
  2.50%  DdbtdCollection::resetHashTableAndCount(void) [LM/AXG561]
  1.92%  DeeMM::allocate(unsigned int, void (*)(void)) [LM/AXG425]
  1.33%  Deeinp_nonBlockingKernelCall [LM/AXG561]
  1.17%  DdbtdCollectionHashTab::DdbtdCollectionHashTab(unsigned int, bool) [LM/AXG561]
  1.17%  Dicos_callKernel_mayBlock [LM/AXG425]
  0.92%  __builtin_vec_new [LM/AXG561]
...

Since the JVM compiles byte codes to machine code stored on the heap, there is
quite a lot of time spent in "JIT or PROM" functions.

--- ACCUMULATED ---
 99.92%   3.00%  DeekCapsule_Local::launchJob(void *) [LM/AXG561]
 73.64%  22.44%  UNKNOWN [(JIT or PROM)]
 73.23%   0.00%  DeekThreadUserCalls::ThreadStartJob::execute(void) [LM/AXG561]
 72.98%   0.08%  JavaCalls::call(JavaValue *, methodHandle, JavaCallArguments *, Thread *) [LM/MD47]
 72.73%   0.08%  JavaCalls::call_helper(JavaValue *, methodHandle *, JavaCallArguments *, Thread *) [LM/MD47]
 71.56%   0.17%  JavaProcess::start(void *) [LM/MD47]
 71.14%   0.58%  jni_invoke(JNIEnv_ *, JavaValue *, _jobject *, JNICallType, _jmethodID *, JNI_ArgumentPusher *, Thread
*) [LM/MD47]
 70.39%   0.08%  JNIEnv_::CallVoidMethod(_jobject *, _jmethodID *,...) [LM/MD47]
 70.23%   0.25%  jni_CallVoidMethodV [LM/MD47]
 40.45%   2.50%  BKC_InterruptEntry [LM/AXG561]
 18.68%   0.08%  Java_se_ericsson_telorb_dbn_Transaction_jniCommitDicosTransaction [LM/MD47]
 17.10%   0.08%  DeekMessageJob::execute(void) [LM/AXG561]
 16.01%   0.08%  DicosDbTransaction::privateCommit(DicosDbBagOfDirtyReads *) [LM/AXG436]
  9.59%   0.42%  DdbtdCollectionKI::closeAll(void) [LM/AXG436]
  8.76%   0.08%  DdbtdCollection::closeAllColl(void *) [LM/AXG561]
...

DeekCapsule_Local::launchJob is where all application execution starts, therefore
it always comes out at the top. Since this is a database intensive application
much time is used in Java_se_ericsson_telorb_dbn_Transaction_jniCommitDicosTransaction
and its called functions

--- BROKEN DOWN ---
...
---
 85.71%  DicosDbTransaction::privateCommit(DicosDbBagOfDirtyReads *) [LM/AXG436]
 12.95%  DicosDbBagOfDirtyReads::closeAll(void) [LM/AXG436]
  0.45%  DdbtdCollectionOfOpens::closeAll(void) [LM/AXG436]
  0.45%  DdbtdCollectionKI::setStateVerifying(void) [LM/AXG436]
  0.45%  (self)
---
...

This tells us that 85% of the time used by Java_se_ericsson_telorb_dbn_Transaction_jniCommitDicosTransaction
is executed while it is calling DicosDbTransaction::privateCommit

---
DicosDbTransaction::privateCommit(DicosDbBagOfDirtyReads *) [LM/AXG436]
 52.60%  DdbtdTransaction::commit(DdbtdCollectionKI *, bool &) [LM/AXG436]
 23.96%  DicosDbTransaction::privateVerify(bool) [LM/AXG436]
 17.71%  DdbtdTransaction::closeAll(void) [LM/AXG436]
  1.04%  DemoPot_Impl::~DemoPot_Impl(void) [LM/D4]
  1.04%  DdbtdSiteList::addSite(DicosProcessorIdentity const &) [LM/AXG436]
  1.04%  DdbtdCollectionKI::setStateVerifying(void) [LM/AXG436]
  0.52%  Dee_traceIsOn [LM/AXG425]
  0.52%  DdbtdCollectionKI::setStateAfterCommitTriggering(void) [LM/AXG436]
  0.52%  DemoPot_Impl::triggerAtClose(void) [LM/D4]
  0.52%  DdbtdCollectionKI::closeAll(void) [LM/AXG436]
  0.52%  (self)
---

which in turn uses half of its time in DdbtdTransaction::commit. And so on.

Finally you have

--- CALL CHAINS ---
DeekCapsule_Local::launchJob(void *) [LM/AXG561=TLM_IPMM_5+0x80fbb]
DeekThreadUserCalls::ThreadStartJob::execute(void) [LM/AXG561=TLM_IPMM_5+0x8e345]
JavaProcess::start(void *) [LM/MD47=R1AB13+0x1afce2]
JNIEnv_::CallVoidMethod(_jobject *, _jmethodID *,...) [LM/MD47=R1AB13+0x1af3e2]
jni_CallVoidMethodV [LM/MD47=R1AB13+0x49bbd]
jni_invoke(JNIEnv_ *, JavaValue *, _jobject *, JNICallType, _jmethodID *, JNI_ArgumentPusher *, Thread *)
[LM/MD47=R1AB13+0x455a2]
JavaCalls::call(JavaValue *, methodHandle, JavaCallArguments *, Thread *) [LM/MD47=R1AB13+0x400bb]
JavaCalls::call_helper(JavaValue *, methodHandle *, JavaCallArguments *, Thread *) [LM/MD47=R1AB13+0x40201]
UNKNOWN [(JIT or PROM)=+0xa006c4a6]
UNKNOWN [(JIT or PROM)=+0xdfd2379d]
UNKNOWN [(JIT or PROM)=+0xdfd26db6]
UNKNOWN [(JIT or PROM)=+0xdfd27299]
UNKNOWN [(JIT or PROM)=+0xdfd27485]
UNKNOWN [(JIT or PROM)=+0xdfd27784]
UNKNOWN [(JIT or PROM)=+0xdfd253e2]
UNKNOWN [(JIT or PROM)=+0xdfd061f5]
UNKNOWN [(JIT or PROM)=+0xdfd27dec]
UNKNOWN [(JIT or PROM)=+0xdfd286be]
UNKNOWN [(JIT or PROM)=+0xdfd2a6e2]
UNKNOWN [(JIT or PROM)=+0xdfd2b263]
UNKNOWN [(JIT or PROM)=+0xdfd0eb57]
UNKNOWN [(JIT or PROM)=+0xdfd1011f]
Java_se_ericsson_telorb_dbn_Transaction_jniCommitDicosTransaction [LM/MD47=R1AB13+0x1ad0be]
DicosDbTransaction::privateCommit(DicosDbBagOfDirtyReads *) [LM/AXG436=R1Z11+0x3b9d6]
DdbtdTransaction::closeAll(void) [LM/AXG436=R1Z11+0x2784c]
DdbtdCollectionKI::closeAll(void) [LM/AXG436=R1Z11+0x77ea]
BKC_InterruptEntry [LM/AXG561=TLM_IPMM_5+0x9a8e4]
DdbtdCollection::closeAllColl(void *) [LM/AXG561=TLM_IPMM_5+0x5360d]
DdbtdCollection::closeAllColl(DdbtdOpenObject *&) [LM/AXG561=TLM_IPMM_5+0x56230]
DdbtdOpenObject::remove(DdbtdOpenObject *) [LM/AXG561=TLM_IPMM_5+0x5bbb0]
DdbsmObject::close(DdbtdOpenObject *, bool) [LM/AXG561=TLM_IPMM_5+0x3e742]
---
...

if you want to take a closer look at the execution paths.

I think that's it.

/Lars


Check heapstat in to28

# Proc_m0_s7
telnet 172.16.16.7 8100
heapstat
quit


# Proc_m0_s9
telnet 172.16.16.9 8100
heapstat
quit


# Proc_m0_s15
telnet 172.16.16.15 8100
heapstat
quit


# Proc_m0_s17
telnet 172.16.16.17 8100
heapstat
quit


# Proc_m0_s19
telnet 172.16.16.19 8100
heapstat
quit


# Proc_m1_s9
telnet 172.16.16.137 8100
heapstat
quit


# Proc_m1_s11
telnet 172.16.16.139 8100
heapstat
quit


# Proc_m1_s19
telnet 172.16.16.147 8100
heapstat
quit


# Proc_m1_s21
telnet 172.16.16.149 8100
heapstat
quit

Start Trace GUI
rlogin uabs31i1c41   (or to another powerful machine that is at least a Sparc
Ultra-5)

cd /home/telorb/to6  (Go to your TelORB system, e.g. to6)

setenv DISPLAY 134.138.186.xx:0.0  (Set IP address of the WS to display on.
                                    Adjust the IP address to the WS that you
                                    are working on)

Edit the file Envsettings to point to the corresponding testbed that is
loaded in the TelORB system.

source Envsettings

/ipims_dicos/BS2/pub/jdk/bin/java -cp
/ipims_dicos/ipims_dicos10/dists/TelORB-AD9.04/examples/tracetool/stt.jar -mx50M mainFrame
(starts the trace tool)

Connect the tool to the running system by right clicking the 'File' pull down
menu, select connect. Fill in the IP address to one of the Plg loaders,
e.g. Enter IP address: 134.138.67.101 

Click the Ok button.

If you see the text 'Connection error' in the connect menu it means that no
trace server answered at the specified address.
   
The tool starts up giving a view of all 'System Areas' (SA), if  you want
another view of the system, right click the Tree pull down menu and select
something else, e.g. LM.

Decide what LM you want to trace in, double click on it with the left button,
and it will expand out the composed of stuff.
 
If there are many LM's you click with the right mouse button in the tree window
to get a small search function.

Double click on an OU to get a list of source files.

Double click an a source file, it will appear in the 
text window.

In the text window select a source code line, go to the line number field, right
click on it and a set trace point menu will appear.
   
Click the set trace point button.
 
The tool must now start analyzing a lot of data in order to translate source
code line into machine code address, so it might take some time (max 1-2 min,
depending on the size of the LM).

Keep a look in the shell window from where the tool was started to see eventual
error printouts.

A line should appear in the Trace point window looking like this:

Example: 'T1 Disabled 0  OU/AXG123:src/mySource.cc:63'

This should be interpreted as follows:

o tracepoint number, T1 means trace point number 1
o tracepoint state, Disabled means just that
o tracepoint hit count, is 0
o tracepoint location, OU/AXG123 file, src/mySource.cc line 63

Right click on the line to get a popup menu.
Select edit.
A new popup is created: Trace point properties.
Select on which processors the tracepoint shall be activated.
Select option 'get call chain' if you want a stack backtrace with the trace
notification (this burns CPU cycles from the off-line system).
Select Ok.

Right click on the Trace point line again and select activate.

The state of the trace point should now have changed to Armed, and notifications
coming in, to the notification window.

For further information please read the following document: 
/ipims_dicos/ipims_dicos10/dists/TelORB-AD9.04/examples/tracetool/traceGui.txt

(Source: E-mail from Peder Magnusson, 1999-09-20)

Get information about DU configuration and on which TelORB processors a DU is
primary and redundant
The DU distribution information is stored on the backup.

Either use the WWW interface:   http://134.138.xx.101:5557/
or the telnet interface:        telnet 134.138.xx.101 8000
                                (Log in to e.g. TelORB processor 1)
                                (Adjust xx to valid network address)
   
Go to directory /SWS/DUTs/ and select the item of interest to get its DU
information. Using telnet, use the cat command, e.g.:
  cat DeAppDU.SWI_DEA9952          (to see the DemoApp DU distribution)
  cat DemoPot_Dut.SWI_D11          (to see the JavaApp DU distribution)

  cat DeTG_Config_DUT.OU_DEA9971   (to see the DemoTG DU distribution)
  cat DeTG_Process_DUT.SWI_DEA9953 (to see the DemoTG_Process DU distribution)
  cat DemoMO_Dut.SWI_D7            (to see the DemoMO DU distribution)
  cat Central_TG_Dut.SWI_D14       (to see the CentralJavaTG DU distribution)
  cat TG_Config_Dut.SWI_D6         (to see the JavaTG DU distribution for Java)
  cat CplusTG_Dut.SWI_D20          (to see the JavaTG DU distribution for C++)

The printout for e.g. DeAppDU.SWI_DEA9952 in AD12.4p3 with 30 TelORB processors
looks something like this:

	Configuration information:
	==========================

	DUT identity: 					524597
	Property: 					3
	Version: 					R1A02
	Distribution limit: 				100
	Start phase: 					1
	Access replicated (true/false): 		0
	Next installed DU: 				0

	Suites:
	=======
	Suite 1			 [0-0]		Prim: 1.18	Red: 1.19
	Suite 2			 [1-1]		Prim: 1.18	Red: 1.20
	Suite 3			 [2-2]		Prim: 1.19	Red: 1.20
	Suite 4			 [3-3]		Prim: 1.19	Red: 1.21
	Suite 5			 [4-4]		Prim: 1.19	Red: 1.22
	Suite 6			 [5-5]		Prim: 1.20	Red: 1.21
	Suite 7			 [6-6]		Prim: 1.20	Red: 1.22
	Suite 8			 [7-7]		Prim: 1.20	Red: 1.23
	Suite 9			 [8-8]		Prim: 1.20	Red: 1.24
	Suite 10		 [9-9]		Prim: 1.21	Red: 1.22
	Suite 11		 [10-10]	Prim: 1.21	Red: 1.23
	Suite 12		 [11-11]	Prim: 1.21	Red: 1.24
	Suite 13		 [12-12]	Prim: 1.21	Red: 1.25
	Suite 14		 [13-13]	Prim: 1.22	Red: 1.23
	Suite 15		 [14-14]	Prim: 1.22	Red: 1.24
	Suite 16		 [15-15]	Prim: 1.22	Red: 1.25
	Suite 17		 [16-16]	Prim: 1.22	Red: 1.26
	Suite 18		 [17-17]	Prim: 1.23	Red: 1.24
	Suite 19		 [18-18]	Prim: 1.23	Red: 1.25
	Suite 20		 [19-19]	Prim: 1.23	Red: 1.26
	Suite 21		 [20-20]	Prim: 1.23	Red: 1.27
	Suite 22		 [21-21]	Prim: 1.24	Red: 1.25
	Suite 23		 [22-22]	Prim: 1.24	Red: 1.26
	Suite 24		 [23-23]	Prim: 1.24	Red: 1.27
	Suite 25		 [24-24]	Prim: 1.24	Red: 1.28
	Suite 26		 [25-25]	Prim: 1.25	Red: 1.26
	Suite 27		 [26-26]	Prim: 1.25	Red: 1.27
	Suite 28		 [27-27]	Prim: 1.25	Red: 1.28
	Suite 29		 [28-28]	Prim: 1.25	Red: 1.29
	Suite 30		 [29-29]	Prim: 1.26	Red: 1.27
	Suite 31		 [30-30]	Prim: 1.26	Red: 1.28
	Suite 32		 [31-31]	Prim: 1.26	Red: 1.29
	Suite 33		 [32-32]	Prim: 1.26	Red: 1.30
	Suite 34		 [33-33]	Prim: 1.27	Red: 1.28
	Suite 35		 [34-34]	Prim: 1.27	Red: 1.29
	Suite 36		 [35-35]	Prim: 1.27	Red: 1.30
	Suite 37		 [36-36]	Prim: 1.27	Red: 1.3
	Suite 38		 [37-37]	Prim: 1.28	Red: 1.29
	Suite 39		 [38-38]	Prim: 1.28	Red: 1.30
	Suite 40		 [39-39]	Prim: 1.28	Red: 1.3
	Suite 41		 [40-40]	Prim: 1.28	Red: 1.4
	Suite 42		 [41-41]	Prim: 1.29	Red: 1.30
	Suite 43		 [42-42]	Prim: 1.29	Red: 1.3
	Suite 44		 [43-43]	Prim: 1.29	Red: 1.4
	Suite 45		 [44-44]	Prim: 1.29	Red: 1.5
	Suite 46		 [45-45]	Prim: 1.30	Red: 1.3
	Suite 47		 [46-46]	Prim: 1.30	Red: 1.4
	Suite 48		 [47-47]	Prim: 1.30	Red: 1.5
	Suite 49		 [48-48]	Prim: 1.30	Red: 1.6
	Suite 50		 [49-49]	Prim: 1.3	Red: 1.4
	Suite 51		 [50-50]	Prim: 1.3	Red: 1.5
	Suite 52		 [51-51]	Prim: 1.3	Red: 1.6
	Suite 53		 [52-52]	Prim: 1.3	Red: 1.7
	Suite 54		 [53-53]	Prim: 1.4	Red: 1.5
	Suite 55		 [54-54]	Prim: 1.4	Red: 1.6
	Suite 56		 [55-55]	Prim: 1.4	Red: 1.7
	Suite 57		 [56-56]	Prim: 1.4	Red: 1.8
	Suite 58		 [57-57]	Prim: 1.5	Red: 1.6
	Suite 59		 [58-58]	Prim: 1.5	Red: 1.7
	Suite 60		 [59-59]	Prim: 1.5	Red: 1.8
	Suite 61		 [60-60]	Prim: 1.5	Red: 1.9
	Suite 62		 [61-61]	Prim: 1.6	Red: 1.7
	Suite 63		 [62-62]	Prim: 1.6	Red: 1.8
	Suite 64		 [63-63]	Prim: 1.6	Red: 1.9
	Suite 65		 [64-64]	Prim: 1.6	Red: 1.10
	Suite 66		 [65-65]	Prim: 1.7	Red: 1.8
	Suite 67		 [66-66]	Prim: 1.7	Red: 1.9
	Suite 68		 [67-67]	Prim: 1.7	Red: 1.10
	Suite 69		 [68-68]	Prim: 1.7	Red: 1.11
	Suite 70		 [69-69]	Prim: 1.8	Red: 1.9
	Suite 71		 [70-70]	Prim: 1.8	Red: 1.10
	Suite 72		 [71-71]	Prim: 1.8	Red: 1.11
	Suite 73		 [72-72]	Prim: 1.9	Red: 1.10
	Suite 74		 [73-73]	Prim: 1.9	Red: 1.11
	Suite 75		 [74-74]	Prim: 1.9	Red: 1.12
	Suite 76		 [75-75]	Prim: 1.10	Red: 1.11
	Suite 77		 [76-76]	Prim: 1.10	Red: 1.12
	Suite 78		 [77-77]	Prim: 1.10	Red: 1.13
	Suite 79		 [78-78]	Prim: 1.11	Red: 1.12
	Suite 80		 [79-79]	Prim: 1.11	Red: 1.13
	Suite 81		 [80-80]	Prim: 1.11	Red: 1.14
	Suite 82		 [81-81]	Prim: 1.12	Red: 1.13
	Suite 83		 [82-82]	Prim: 1.12	Red: 1.14
	Suite 84		 [83-83]	Prim: 1.12	Red: 1.15
	Suite 85		 [84-84]	Prim: 1.13	Red: 1.14
	Suite 86		 [85-85]	Prim: 1.13	Red: 1.15
	Suite 87		 [86-86]	Prim: 1.13	Red: 1.16
	Suite 88		 [87-87]	Prim: 1.14	Red: 1.15
	Suite 89		 [88-88]	Prim: 1.14	Red: 1.16
	Suite 90		 [89-89]	Prim: 1.14	Red: 1.17
	Suite 91		 [90-90]	Prim: 1.15	Red: 1.16
	Suite 92		 [91-91]	Prim: 1.15	Red: 1.17
	Suite 93		 [92-92]	Prim: 1.15	Red: 1.18
	Suite 94		 [93-93]	Prim: 1.16	Red: 1.17
	Suite 95		 [94-94]	Prim: 1.16	Red: 1.18
	Suite 96		 [95-95]	Prim: 1.16	Red: 1.19
	Suite 97		 [96-96]	Prim: 1.17	Red: 1.18
	Suite 98		 [97-97]	Prim: 1.17	Red: 1.19
	Suite 99		 [98-98]	Prim: 1.17	Red: 1.20
	Suite 100		 [99-99]	Prim: 1.18	Red: 1.19

To quit the telnet session:     quit

Check to which DU an MDP (data part of DU) belongs
Divide the MDP number with 1024, e.g. for MDP 1025833985:
1025833985/1024=1001791 => 1001791=TelORB netshared DU

Check to which software a certain process belongs
 (Updated: 2005-02-17 for TSP5)

E.g. check to which software the following process belongs:
  "Proc_m0_s13:LOG_ERR: DeedugCentral.cci:263 [SCC/AXG73 R50S02]  Static process restarted with id 1025485"
    -or
  "Proc_m0_s9:TelORB Broker (Java) : Getting Client Side Connection for : Persistent : [ 1025485, 0, 0 ] : 4"

From one of the IO processors (adjust 1025485 to a PID valid for you):
  grep 1025485 /opt/telorb/axe/loadingGroup01_1/<name>.config

  Example of printout:
    PT:1025485,1,1:QoSCppTargetProc:OU/IIOPTEST12:R1C01:1025487,1,1:OU/IIOPTEST12:QoSCppTarget_DU:IDP/IIOPTEST4:IIOPFunctionTest:Central:1
  End of printout example.

PRA for APZ 302 02/1 R1A (AD12.4p2)
On Friday June 30th 2000, APZ 302 02/1 R1A reached PRA level. This release of
APZ302 consisted of major enhancements of TelORB and integration and
certification of Pentium III processors. The release is an output of the
Carmencita project.
 
This TelORB version consists of, amongst other improvements, significant
enhancements to the Geographical Network Redundancy functionality. It also
contains real time improvements of the Java environment in the form of the Hot
Spot Java virtual machine. 

The Pentium III processors run with 500 MHz and 768 MByte of RAM and gives a
capacity increase of around 3 times compared to the existing Pentium classic
processors. A two cabinet configuration, base and expansion cabinet, can house
30 Pentium III processors which is an increase of 9 processors compared to the
existing APZ302. This capacity gain is expected to serve nodes of 2-2.5 millions
of TDMA HLR subscribers. This will now be confirmed when PU-SCSA certifies
the system with the HLR application. 

For more information about APZ 302, please see: 
http://uabweb.uab.ericsson.se/presentation/products/osp/index.htm

and TelORB: 
http://internal.ericsson.com/page/hub_corenetwork/unit/pdu_packetserverplatform/org_resources/sub_units/dc_tsp_signaling/sub_units/tsp_clusterware/index.jsp
http://www.ericsson.se/review

and project Carmencita: 
http://uabweb.uab.ericsson.se/inside/units/f/projects/Carmencita

(Source: UAB Home Page, 2000-07-06)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

PRA for APZ 302 02/1 R1A (R13)
On Monday October 16th 2000 PRA was recommended for:
APZ 302 01/1 R4A (Nora HW) &
APZ 302 02/1 R2A (Carmencita HW)

These products include TelORB R13 and SDE 3.0.

(Source: Excerpt from e-mail sent by Bo Andrén, 2000-10-16)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

TelORB R13 project ended with PRA
TelORB R13 and SDE3.0 (Software Development Environment), results from the
Carmen project, were released on schedule. The PRA status was achieved on
October 16th, as planned. 

Some of the main features in this issue are: 
- Partitioned network redundancy, which allows two geographically separate nodes
  to share traffic during normal operation and serve as back-up for each other
  in case of severe disasters such as fires or earthquakes. 
- Java execution environment improvements. 
- Upgrades and extensions of the CORBA environment. 
- Support for SSL (Secure Socket Layer) enabled applications. This function
  provides possibilities to encrypt/decrypt messages. 
- Improved back-up and reload times. 
- The news from the SDE3.0 release is that the software development environment
  is now available for not only Solaris but also NT and Linux. 

TelORB is the enabling software platform in APZ 302 used by the Jambala product family and in WAP gateways.
Jamabala products include HLRs, AUCs, SCPs and ILRs (supporting roaming between
TDMA and GSM). Since the first commercial introduction mid last year, the
installed subscriber base has now increased to more than 8 million. 

For more information on TelORB and APZ 302, visit: 
http://uabweb.uab.ericsson.se/inside/units/f/

Or contact Product Manager Bo Andrén, UAB/F/S. 

(Source: UAB Home Page, 2000-11-15)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Goodbye AD7
Jambala HLR 1.0 AD 7.54 to HLR 1.1 AD 9.05 has been successfully migrated this
morning in NZ (local time 04:00 am Thursday Nov 23) with 204K hlr subs, with
this I'd like to say farewell to AD 7.54.

(Source: Excerpt from an Angelo Coluni e-mail that uabnasl forwarded, 2000-11-27)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

APZ names
Nora:        APZ 302 01/1
Carmencita:  APZ 302 02/1
Box:         APZ 302 03/1

General
 (Updated: 2004-01-27)

Outage history will be removed from TelorbManager/CLI.
Please note that the OutageHistory process is still needed for ISPStatistics,
it will only be removed from the Operator view.
Maybe in a future release should Outage history become a part of
ISPStatistics....

Anyway, if you want to refer to information presented by Outage history, you
should refer to ISPStatistics and the documenatation around it.

(Source: E-mail from Babbis Xagorarakis, 2004-01-27, slightly modified by Michel)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

General
 (Updated: 2001-06-04)

There are three types of outage reports, i.e. availability outage, data outage
and netred outage.

An availability outage is received after a zone reload.
It spans from when the system starts reloading until the zone is available
again.

A data outage is received after a zone reload.
It spans from when the last backup was created until the zone is available
again. 

A netred outage is received after a zone reload of one of the zones (or both)
in a netred system.
It spans from when the system starts reloading until the zone is available again.
A netred outage is only generated for the reloading zone's own partitions, i.e.
for the partitions where the zone is (primary) owner. This means that a zone
reload in zone 1 will result in a netred outage for the partitions 1.2 and a
zone reload in zone 2 will result in a netred outage for the partitions 2.1. 

Examples of outage files:
to8io2:Outage>ls -l
total 20
-rwxrwxrwx   1 telorb   telorb       300 Apr 25 15:26 OutageReport200104251327*
-rwxrwxrwx   1 telorb   telorb       300 May  9 13:52 OutageReport200105091152*
-rwxrwxrwx   1 telorb   telorb       300 May 10 12:51 OutageReport200105101051*
-rwxrwxrwx   1 telorb   telorb       300 May 10 13:05 OutageReport200105101105*
-rwxrwxrwx   1 telorb   telorb       300 May 11 10:28 OutageReport200105110828*
-rwxrwxrwx   1 telorb   telorb       300 May 11 11:06 OutageReport200105110906*
-rwxrwxrwx   1 telorb   telorb       300 May 11 12:08 OutageReport200105111008*
-rwxrwxrwx   1 telorb   telorb       300 May 11 13:13 OutageReport200105111113*
-rwxrw-rw-   1 telorb   telorb       300 May 16 11:04 OutageReport200105160904*
-rwxrwxrwx   1 telorb   telorb         8 May 16 13:19 TimeStamp*

Netred outage creates the following files:
  NetRedOutage...
  permLog       (This file contains a history list of the netred modes that a
                 system has had (1=Netshared?, 2=TakeOver?, 3=Down?).)
                (This file should not be removed when clicking the outage
                 removal button, which however does not yet exist.)
  tmpLog

General
 (Updated: 2001-06-04)

Use the TelORB Manager to initiate interzone IPC links between the zones.
It is enough to specify the link in one of the zones (any zone will do).
Specify the IP address to a TelORB processor in the opposite zone and specify
a port address, which can be found in the console printouts when starting the
processor.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Add interzone IPC link
 (Updated: 2001-06-04)

Add IZIPC link: Processor1, 134.138.63.131, 6501
                                (Adjust Processor1 to valid TelORB processor and
                                 134.138.63.131 to valid IP address)
Printout in P1:
IPC Adaptation driver: Received command
---Received addConfigLink towards (833f8a86), 134.138.63.131/6501
-----> Sending conf msg towards (833f8a86)134.138.63.131/6501
Announcing link to [2.1.1]  with IP address 134.138.64.131/6501
-----> Established link through UDP to [2.1.1]
Printout in P2:
Announcing link to [1.1.1]  with IP address 134.138.64.31/6501
-----> Established link through UDP to [1.1.1]

General
 (Updated: 2001-09-26)

The VIP functionality in TelORB was introduced in TelORB R14 patch 3, 2001-09-26.

The VIP instructions may be outdated, since they were written during the design
phase of the VIP functionality. I will update this section as time permits.

In TelORB, the VIP scenario is where a TelORB zone is connected to an external
network in such a way that the network only sees one IP address. In this case,
all the external network should see is a number of connection points that it
perceives as routers that are all able to forward IP packets to the same IP
host.

Node interconnection is done with a VIP addressing scheme that allows the node
to be addressed by a single IP address representing a connection point. A node
may however contain several such connection points. The interfacing routers will
distribute incoming IP packets to TPs in a round robin or random way. Receiving
TP may further distribute processing within the node.
Geographical redundant TelORB nodes will use this solution in a symmetrical way.
TelORB may also interface other cooperating non-TelORB nodes in the same way.

(TelORB may interface external cooperating non-TelORB nodes using VIP
 addressing. Access to the TelORB zone via a single (or a few) IP address(es)
 will be supported with loadsharing across pools or processors.)
("VIP processor" = TelORB processor with VIP functionality.)

There is a VIP test application designed by Abdallah Chatila at LMC. To get
information about the test application, click on the following link:
DsSocket Test Application for VIP.
The version of the document has probably been updated, but this is the version
which was valid 2001-06-12.
The test application can be found in tbTEST1.3 with MI id IDP/DSS01. (The
documentation will go to SE/DSS01.)

(According to Change Request 44, System I&V will verify the routers
 Cisco 3660 and 3745.)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

TSP 5.0: Install VIP in systems at the EAB CW/OS lab
 (Updated: 2003-12-11)

(Source: E-mail from Jorge Martinez, 2003-11-17, slightly modified by Michel)

This subsection will be cleaned up at a later occasion.

The following is the procedure to activate the ethernet interface on VIP
processors and to configure the VIP interface via the Telorb Manager.

There are two different ways to configure/activate the VIP interface.
I recommend the first one to save time.

1) Build the loadingGroups with VIP configuration. (Configuration
   defined in the epct file.)
2) Build the loadingGroups without VIP configuration. (Comment out VIP
   configuration in epct file.)

In both cases, LM/PRO801 from tbTEST15.0 must be set. 


1) Build the loadingGroups with VIP configuration.

   - Add the following to your epct file:

       // Environment Data Parameters for VIP traffic (CW/OS lab specific)
       // ===========================================

       ENVIRONMENT DATA

       VIP_TRAFFIC_RECEIVER_CONFIGPORT = "5987"
       VIP_TRAFFIC_RECEIVER_TRAFFICPORT = "5988"
       VIP_TRAFFIC_RECEIVER_STRESS = "1"
       VIP_TRAFFIC_RECEIVER_DEBUG = "0"

       ENDDATA

   - When the system is up and running, log into the VIP processor and activate
     the VIP interface, e.g.:

     linux:/home/telorb # ifconfig eth2
       eth2      Link encap:Ethernet  HWaddr 00:80:37:8F:34:88  
                 BROADCAST MULTICAST  MTU:1500  Metric:1
                 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
                 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
                 collisions:0 txqueuelen:100 
                 RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
                 Interrupt:10 Base address:0xd000 Memory:e8041000-e8041038 

     Activate the interface: Check in dhcp.pxe.conf which ip address that was
     defined for your VIP processor(s) and configure it/them as follows:
     E.g.:
       linux:/home/telorb # ifconfig eth2 inet 192.168.76.80 
       linux:/home/telorb # ifconfig eth2
       eth2      Link encap:Ethernet  HWaddr 00:80:37:8F:34:88  
                 inet addr:192.168.76.80  Bcast:192.168.76.255 
                 Mask:255.255.255.0
                 inet6 addr: fe80::280:37ff:fe8f:3488/64 Scope:Link
                 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
                 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
                 collisions:0 txqueuelen:100 
                 RX bytes:50 (50.0 b)  TX bytes:148 (148.0 b)
                 Interrupt:10 Base address:0xd000 Memory:e8041000-e8041038

   - On the TelorbManager, click on the "Virtual IP" button and do the
     following:
     Mark the i4dd0 interface on "VIP Distribution Devices" window. The next
     step is to remove the "Gateways" configuration and to add  
     the same information again. So before removing it, Write down the
     information you have and add it again.
     Try to ping the "Vip Distribution Device (i4dd0) IP" before starting the
     VIPtraffic.(From a WS). If the ping results are good, start the
     VIPtrafficGenerator and then set the proper settings for external vip
     traffic on TSP ref APP.


2) Build the loadingGroups without VIP configuration.

   - Comment out the information you have on the epct file, e.g.:

     //i4ddCommand_300 = "ddconfig i4dd0 Proc_m0_s17:eth2:192.168.76.1
Proc_m0_s19:eth3:192.168.77.2"

     //i4ddCommand_310 = "ifconfig i4dd0 inet 134.138.71.28"

     //i4ddCommand_320 = "route add default -interface i4dd0"

     //SocketUserDistributionCfg_1 = "0x800:6:0:roundRobinDistributor"
     //SocketUserDistributionCfg_2 = "0x800:17:0:roundRobinDistributor" 

     Note:
     Router internal interface IP: 192.168.76.1
     Vip Distribution Device (i4dd0) IP: 134.138.71.28 (e.g. to28=28)

   - When the system is up and running, log in via ssh to the VIP-Proc and
     active the VIP ethernet interface.

     The information that resides in your dhcp.pxe.conf file regarding VIP
     interface will not work, so you have to configure the interface manually.

   - Log into a VIP_Proc via one of the internal interfaces with "telorb" as
     passwd. Check that the VIP interface has been identified by Linux OS as
     follows, e.g. 

     linux:/home/telorb # ifconfig eth2
     eth2      Link encap:Ethernet  HWaddr 00:80:37:8F:34:88  
               BROADCAST MULTICAST  MTU:1500  Metric:1
               RX packets:0 errors:0 dropped:0 overruns:0 frame:0
               TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
               collisions:0 txqueuelen:100 
               RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
               Interrupt:10 Base address:0xd000 Memory:e8041000-e8041038 

   - Activate the interface: Check in dhcp.pxe.conf which ip address was
     defined for your VIP proc.

     linux:/home/telorb # ifconfig eth2 inet 192.168.76.80 
     linux:/home/telorb # ifconfig eth2
     eth2      Link encap:Ethernet  HWaddr 00:80:37:8F:34:88  
               inet addr:192.168.76.80  Bcast:192.168.76.255 
               Mask:255.255.255.0
               inet6 addr: fe80::280:37ff:fe8f:3488/64 Scope:Link
               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
               RX packets:0 errors:0 dropped:0 overruns:0 frame:0
               TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
               collisions:0 txqueuelen:100 
               RX bytes:50 (50.0 b)  TX bytes:148 (148.0 b)
               Interrupt:10 Base address:0xd000 Memory:e8041000-e8041038 

---------------------------------------------------------------------

   - Try to ping the router to see if you have a connection between the
     router and the VIP processor(s), e.g.

     linux:/home/telorb # ping 192.168.76.1
     PING 192.168.76.1 (192.168.76.1) from 192.168.76.80 : 56(84) bytes of
     data.
     64 bytes from 192.168.76.1: icmp_seq=1 ttl=64 time=4.64 ms
     64 bytes from 192.168.76.1: icmp_seq=2 ttl=64 time=0.223 ms
     64 bytes from 192.168.76.1: icmp_seq=3 ttl=64 time=0.205 ms


     Configure the VIP interface via TelorbManager as follows:

     Click on the Virtual IP button and configure i4dd0 device.

     On the Vip Distribution Device window:

     Add: i4dd0
     Mark "i4dd0" and then configure the ethernet interface on the "Gateways"
     window.
     ex:
     Add -> Procesor:Proc_m0_s17 Network interface:eth2 Gateway:192.168.76.1
     On the Configure Vip mapping windows, add the following:
     IP Type:ip
     Protocol:tcp
     Port number:0
     Distribution Function:roundRobinDistributor

---------------------------------------------------------------------

     Click on the Network button.

     Click on refresch button on the "configured IP Devices" window.
     Mark the i4dd0 interface and click on the "Modify" button:
     Activate the interface "up"
     Enter the Vip Distribution Device (i4dd0) IP.
     Parameters:leave it blank

     On the "Network Routes" window add the following.

     Click Add button.
     Destination:0.0.0.0 (or default)
     Netmasks:0.0.0.0
     Gateway:-interface i4dd0 (or Vip Distribution Device (i4dd0) IP).

---------------------------------------------------------------------

     Check on the VIP processor that i4dd0 interface is up and running. Use
     "ifconfig i4dd0" command.

     ex:

---------------------------------------------------------------------

     linux:/home/telorb # ifconfig i4dd0
     i4dd0     Link encap:UNSPEC  HWaddr
     FF-FF-FF-FF-FF-FF-00-00-00-00-00-00-00-00-00-00  
          inet addr:134.138.71.28  Mask:255.255.255.255
          UP RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

---------------------------------------------------------------------

     Both the VIP interface and VIP configuration are ready. Try to ping the
     "Vip Distribution Device (i4dd0) IP" before starting the VIPtraffic.

(Source: E-mail from Jorge Martinez, 2003-11-17, slightly modified by Michel)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

VIP configuration
 (Updated: 2001-11-06)

The information in this section was written by uabmat, since the instructions
that I wrote in the sections below have become outdated.

Be sure to substitute any TelORB system specific data, such as IP addresses and
IO processor names, with what is valid for the TelORB system that you are
running.

epct
----

Add the following lines in the epct file:

# VIP addressing
# Define all VIP nets (use internal IP addresses)
i4ddCommand_0 = "ddconfig i4dd0 Processor8:eth0:192.168.63.1
Processor16:eth0:192.168.63.5"
# Define VIP addresses (use IP addresses from own TelORB system + 2,
e.g. use
# to22 addresses for to20, start with 10 for lower net part and 240 for
higher
# net part)
i4ddCommand_1 = "ifconfig i4dd0 inet 134.138.63.10"
#//i4ddCommand_2 = "route add -net 192.168.135.0/24 -interface i4dd0"
# Delete default router set by dhcpd.pxe.conf
i4ddCommand_2 = "route delete default"
# Define VIP address as default router
i4ddCommand_3 = "route add default -interface i4dd0"
#//i4ddCommand_4 = "route add -host 192.168.130.25 -interface lo0"
# Set up VIP firewall, 17=UDP/IP, 6=TCP/IP, 0=completely open
SocketUserDistributionCfg_0 = "0x800:17:0:roundRobinDistributor"
SocketUserDistributionCfg_1 = "0x800:6:0:roundRobinDistributor"

// VIP test program stuff
// ----------------------
// If this variable is set to 0, then each server process will 
// listen/service all ports defined by the DsTest_portsBase and 
// DsTest_numberOfPorts variables
DsTest_distributeServerPortsOnAllProcessors = 0

SOFTWARE
        LM/DSS2;                // DsTestServerProcess, for VIP testing,
Optional, LM/DSS3 DsTestUnixClient will be
executing on an IO (or linux) processor

POOL DsTestServerPool;
ALLOCATE ServerProcessDUT TO DsTestServerPool;

PROCESSOR Processor1 ALSO IN DsTestServerPool;
...
PROCESSOR Processor30 ALSO IN DsTestServerPool;


ENVIRONMENT DATA
DsTest_disableClientProcess=1
DsTest_distributeServerPortsOnAllProcessors=0
DsTest_useOneSessionServerPerPort=1
DsTest_delayBetweenServerRestartsOnPort=1
ENDDATA


TelORB Manager
--------------
Virtual IP:
Configured VIP Mappings - Add
ip
tcp
0
roundRobinDistributor

VIP Distributor Devices - Add
i4dd0

Gateways - Add
Processor7
eth2
134.138.76.1

Gateways - Add
Processor8
eth2
134.138.76.5

Network:
Configured IP Devices - Refresh - Modify
Up
Address 192.168.76.10

Network Routes - Add
default

-interface i4dd0

(i4dd0 = Logical distributor device)

IO (or linux) processor
-----------------------

telnet to22io1
cd /opt/telorb/vip
setenv DsTest_host 134.138.76.10
setenv DsTest_numOfMessages 10
setenv DsTest_delayBetweenPortsConnection 200
DsSocket_IDP/UnixClientProcess_LM/bin/DsTestUnixClient.LM_DSS3.R1A04.sparc-SunOS-5.6

(ssh telorb@ulinpc52
setenv DsTest_host 134.138.76.10
to22io1:vip>setenv DsTest_numOfMessages 10
setenv DsTest_delayBetweenPortsConnection 200
cd vip
DsSocket_IDP/UnixClientProcess_LM/bin/DsTestUnixClient.LM_DSS3.R1A04.i486-Redhat-6.0
or
DsTest_host=192.168.76.10
DsTest_numOfMessages=10
DsTest_delayBetweenPortsConnection=200
export DsTest_host DsTest_numOfMessages
DsTest_delayBetweenPortsConnection
DsSocket_IDP/UnixClientProcess_LM/bin/DsTestUnixClient.LM_DSS3.R1A04.i486-Redhat-6.0)


Create a backup and zone reload the system in order to get the test
program settings OK.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

VIP alias and External non-VIP interface
========================================
Två konfigurationsändringar som jag anser att ALLA testare ska lägga in redan innan steg 1, se nedan. Jag har skrivit vad jag TROR vi behöver kolla. Frasse får väl rätta mig om jag är på avvägar!

För "VIP alias" kan det testas (gissar jag) genom att köra VIP trafik mot alias-adressen och VIP-adressen samtidigt. Trafiken ska överleva steg 4 och även alias ska följa med genom den långa steg4-tunneln.

För externa ickeVIP-interface så räcker det nog med att definiera dem och att de går att pinga med direktkoppling till interfacet. De ska framför allt gå igenom nålsögat tillsammans med resten av elefanten vid steg4.

Det skulle med minimal sannolikhet kunna bli problem med den externa VIP-trafikgeneratorn (LM/VIP101) under steg4 pga av olika versioner, men det är inte troligt.

--------------------------

1) VIP alias

Lägg in i epct vid de övriga i4dd-kommandona. Det är troligen så att det bara handlar om att lägga till alias när man definierar VIP-adressen:

i4ddCommand_310 = "ifconfig i4dd0 inet 172.30.14.20 alias 172.30.14.60"

Här är alltså 172.30.14.20 den "riktiga" VIP-adressen och 172.30.14.60 alias. Se till att välja ett alias som inte är upptaget! Jag har tagit 172.30.14.60

--------------------------

2) Externa non-VIP interface

Här är ett klipp ur en telorb.conf-template. Klipp in rubbet eller ta de väsentliga delarna. Editera sedan MAC-adresser och IP-adresser! Det går nog i princip att ta vilken IP-adress som helst som inte är upptagen i systemet (undvik tex 134.138.x.y, 172.30.x.y samt 192.x.y.z). Jag har använt 100.100.100.0, se nedan. Jag har också varit ett jävla hygglo och lagt in hela mitt exempel (minus MAC-adresser). Ni kan då tex bara byta ut det första 100 mot tex 101. Även här är det nog bra att undvika att ta något som någon annan redan använder. Ping to check if in use.

# Configuration of TelORB Processors with non-VIP interface (eth2 & eth3)
# =======================================================================
# It is possible to configure eth2 and eth3 on the TelORB processors as
# external non-VIP interfaces.
#
# WARNING - This feature is introduced only for one particular application
#           that has requirements that mean that VIP cannot currently be used.
#           This feature should not be used by other applications without first
#           consulting System Management at CCND.
#
# The non-VIP option is only valid for TelORB processors running with Dicos.
#
# Adjust the following for each non-VIP interface:
# - externalnonvip-network extnetX:     Specify IP address to your external
#                                       non-VIP network, e.g. 134.138.10.0.
# - externalnonvip-network extnetmaskX: Specify netmask for extnetX, e.g.
#                                       255.255.255.0.
# - externalnonvip-network defaultgwX:  Specify default gateway for extnetX,
#                                       e.g. 134.138.10.1.
# - ip_addr_for_extX:                   Specify IP address of the non-VIP
#                                       interface connected to the external
#                                       network, e.g. 134.138.10.10.
# - eth_addr_for_extX:                  Specify MAC address of ip_addr_for_extX,
#                                       e.g.
#          externalnonvip_dicosProc_m0_s21_2 eth_addr_for_ext1 00:20:ce:c8:00:7f
#                                       for eth2 and
#          externalnonvip_dicosProc_m0_s23_3 eth_addr_for_ext1 00:20:ce:c8:00:8e
#                                       for eth3.
#                                       Proc_m0_s21_2 and Proc_m0_s23_3 are used
#                                       as examples.

#externalnonvip-network extnet0 aae.bbe.cce.dde
#externalnonvip-network extnetmask0 aaf.bbf.ccf.ddf
#externalnonvip-network defaultgw0 aag.bbg.ccg.ddg
#externalnonvip_dicosProc_m0_s21_2 ip_addr_for_ext0 aah.bbh.cch.ddh
#externalnonvip_dicosProc_m0_s21_2 eth_addr_for_ext0 xx:xx:xx:xx:xx:xx

#externalnonvip-network extnet1 aai.bbi.cci.ddi
#externalnonvip-network extnetmask1 aaj.bbj.ccj.ddj
#externalnonvip-network defaultgw1 aak.bbk.cck.ddk
#externalnonvip_dicosProc_m0_s23_3 ip_addr_for_ext1 aal.bbl.ccl.ddl
#externalnonvip_dicosProc_m0_s23_3 eth_addr_for_ext1 xx:xx:xx:xx:xx:xx

============================

Krister's example:
##################
externalnonvip-network extnet0 100.100.100.0
externalnonvip-network extnetmask0 255.255.255.224
externalnonvip-network defaultgw0 100.100.100.1
externalnonvip_dicosProc_m0_s21_2 ip_addr_for_ext0 100.100.100.21
externalnonvip_dicosProc_m0_s21_2 eth_addr_for_ext0 00:20:ce:c9:81:74
externalnonvip_dicosProc_m0_s23_2 ip_addr_for_ext0 100.100.100.23
externalnonvip_dicosProc_m0_s23_2 eth_addr_for_ext0 00:20:ce:c9:d0:34

externalnonvip-network extnet1 100.100.100.96
externalnonvip-network extnetmask1 255.255.255.224
externalnonvip-network defaultgw1 100.100.100.97
externalnonvip_dicosProc_m0_s23_3 ip_addr_for_ext1 100.100.100.123
externalnonvip_dicosProc_m0_s23_3 eth_addr_for_ext1 00:20:ce:c9:d0:35
externalnonvip_dicosProc_m0_s21_3 ip_addr_for_ext1 100.100.100.121
externalnonvip_dicosProc_m0_s21_3 eth_addr_for_ext1 00:20:ce:c9:81:75
--------------------------

Source: E-mail from Krister Nilsson, 2005-09-21

== == == == == == == == == == == == == == == == == == == == == == == == == ==

VIP configuration in the EAB CW/OS lab
 (Updated: 2002-09-02)

Valid for the following TelORB systems: to22, to23, to27, to28, to29.

VIP_Router_01
-------------
  IP addresses: 134.138.71.2 (eth0)
                192.168.76.1 (eth1)
                192.168.77.1 (eth2)

VIP_Router_02
-------------
  IP addresses: 134.138.71.6 (eth0)
                192.168.76.2 (eth1)
                192.168.77.2 (eth2)

CiscoRouter1    (Updated info: 2005-07-12)
------------
  IP address: 134.138.12.23  (telnet, telorb)

CiscoRouter2    (Updated info: 2005-07-12)
------------
  IP address: 134.138.12.24  (telnet, telorb)

CiscoRouterCommon    (Updated info: 2005-07-12)
-----------------
  IP address: 134.138.12.23  (Common IP address to the CiscoRouter which is
                              primary) (telnet, telorb)

to22
----
  VIP address:  172.30.14.22 (Old: 134.138.71.22)
  IP addresses: 192.168.76.20 - 192.168.76.39 (eth2)
                192.168.77.20 - 192.168.77.39 (eth3)

to23
----
  VIP address:  172.30.14.23 (Old: 134.138.71.23)
  IP addresses: 192.168.76.40 - 192.168.76.59 (eth2)
                192.168.77.40 - 192.168.77.59 (eth3)

to27
----
  VIP address:  172.30.14.27 (Old: 134.138.71.27)
  IP addresses: 192.168.76.60 - 192.168.76.79 (eth2)
                192.168.77.60 - 192.168.77.79 (eth3)

to28
----
  VIP address:  172.30.14.28 (Old: 134.138.71.28)
  IP addresses: 192.168.76.80 - 192.168.76.99 (eth2)
                192.168.77.80 - 192.168.77.99 (eth3)

to29
----
  VIP address:  172.30.14.29 (Old: 134.138.71.29)
  IP addresses: 192.168.76.100 - 192.168.76.119 (eth2)
                192.168.77.100 - 192.168.77.119 (eth3)

Netmask for all systems (192.168): 255.255.255.0 configured in
VIP routers 1 and 2, as well as in telorb.conf.


                ==================================================
                | PC ulinpc52 to execute the VIP test program on |
                ==================================================
                                     | 134.138.184.175
                                     |
                                     | 134.138.17.2
 =============================================================================
 |                  EAB CW/OS lab router (XYLAN OmniStack)                   |
 =============================================================================
            | 134.138.71.1                            | 134.138.71.5
            |                          R              |
            | (134.138.71.0)           I              | (134.138.71.4)
            |                          P              |
            | 134.138.71.2                            | 134.138.71.6
            | eth0                                    | eth0
 ===================================       ===================================
 |          VIP Router 1           |       |          VIP Router 2           |
 ===================================       ===================================
   | 192.168.76.1    | 192.168.77.1    O     | 192.168.76.2    | 192.168.77.2
   | eth1            | eth2            S     | eth1            | eth2
   |                 |                 P     |                 |
   | (192.168.76.0)  | (192.168.77.0)  F     | (192.168.76.0)  | (192.168.77.0)
   |                 |                       |                 |
   |                 |   ---------------------                 |
   |                 |   |                                     |
   |                 ---------------------------               |
   |                     |                     |               |
   | SW1-port 1          | SW1-port 2          | SW2-port 1    | SW2-port 2
 ===================================       ===================================
 |       VIP Switch 1 (SW1)        |       |       VIP Switch 2 (SW2)        |
 |      (Lucent Cajun P333T)       |       |      (Lucent Cajun P333T)       |
 |                                 |       |                                 |
 | All ports are configured as one |       | All ports are configured as one |
 | LAN. Acts as net 192.168.76.    |       | LAN. Acts as net 192.168.77.    |
 ===================================       ===================================
   | SW1-port 3          | SW1-port 4          | SW2-port 3    | SW2-port 4 
   |                     |                     |               |
   |                ----------------------------               |
   |                |    |                                     |
   |                |    ---------------------                 |
   |                |                        |                 |
   | 192.168.76.20  | 192.168.77.20          | 192.168.76.21   | 192.168.77.21
   | eth2           | eth3                   | eth2            | eth3
 ===================================       ===================================
 |       to22 : Processor7         |       |       to22 : Processor8         |
 ===================================       ===================================


   | SW1-port 5     | SW2-port 6             | SW1-port 5     | SW2-port 6 
   |                |                        |                |
   | 192.168.76.40  | 192.168.77.40          | 192.168.76.41  | 192.168.77.41
   | eth2           | eth3                   | eth2           | eth3
 ===================================       ===================================
 |       to23 : Processor?         |       |       to23 : Processor?         |
 ===================================       ===================================


   | SW1-port 7     | SW2-port 8             | SW1-port 7     | SW2-port 8 
   |                |                        |                |
   | 192.168.76.60  | 192.168.77.60          | 192.168.76.61  | 192.168.77.61
   | eth2           | eth3                   | eth2           | eth3
 ===================================       ===================================
 |       to27 : Proc_m0_s??        |       |       to27 : Proc_m0_s??        |
 ===================================       ===================================


   | SW1-port 9     | SW2-port 10            | SW1-port 9     | SW2-port 10
   |                |                        |                |
   | 192.168.76.80  | 192.168.77.80          | 192.168.76.81  | 192.168.77.81
   | eth2           | eth3                   | eth2           | eth3
 ===================================       ===================================
 |       to28 : Proc_m0_s17        |       |       to28 : Proc_m0_s19        |
 ===================================       ===================================


   | SW1-port 11    | SW2-port 12            | SW1-port 11    | SW2-port 12
   |                |                        |                |
   | 192.168.76.100 | 192.168.77.100         | 192.168.76.101 | 192.168.77.101
   | eth2           | eth3                   | eth2           | eth3
 ===================================       ===================================
 |       to29 : Proc_m0_s19        |       |       to29 : Proc_m1_s19        |
 ===================================       ===================================


TP board connectors: Lower=eth2, Upper=eth3.


VIP settings for e.g. to28 in epct
----------------------------------

SOFTWARE IDP/D32;	// NetInet_IDP, VIP (Optional)
SOFTWARE IDP/D35;	// NetInetProcess_IDP, VIP (Optional)
SOFTWARE IDP/D48;	// TelorbLinuxNetInet_IDP, VIP (Optional)
SOFTWARE IDP/D49;	// TelorbLinuxNetInetProcess_IDP, VIP (Optional)
  :
  :
i4ddCommand_300 = "ddconfig i4dd0 Proc_m0_s17:eth2:192.168.76.1 Proc_m0_s17:eth2:192.168.76.2 Proc_m0_s19:eth3:192.168.77.1 Proc_m0_s19:eth3:192.168.77.2"

i4ddCommand_310 = "ifconfig i4dd0 inet 134.138.71.28"

i4ddCommand_320 = "route add default -interface i4dd0"

SocketUserDistributionCfg_1 = "0x800:6:0:roundRobinDistributor"
SocketUserDistributionCfg_2 = "0x800:17:0:roundRobinDistributor"

    (where 0x800=IPv4, 6=IPPROTO_TCP, 17=IPPROTO_UDP, 0=All ports)


    (This corresponds to the following data in the TelORB Manager:

     Configured VIP Mappings:  IPv4   IPPROTO_TCP   0   roundRobinDistributor
                               IPv4   IPPROTO_UDP   0   roundRobinDistributor
     VIP Distribution Devices: i4dd0
     Gateways:                 Proc_m0_s17   eth2   192.168.76.1
                               Proc_m0_s17   eth2   192.168.76.1
                               Proc_m0_s19   eth3   192.168.77.1
                               Proc_m0_s19   eth3   192.168.77.2)

-    -    -    -    -

File viptest_dicos.epct:

//SOFTWARE IDP/D51;	// TcpTestServer for TSP-Linux
SOFTWARE IDP/DSS01;
PROCESSOR Proc_m0_s7 ALSO IN DsTestServerPool;
PROCESSOR Proc_m0_s9 ALSO IN DsTestClientPool;
PROCESSOR Proc_m0_s15 ALSO IN DsTestServerPool;
PROCESSOR Proc_m0_s17 ALSO IN DsTestServerPool;
PROCESSOR Proc_m0_s19 ALSO IN DsTestServerPool;
PROCESSOR Proc_m1_s9 ALSO IN DsTestClientPool;
PROCESSOR Proc_m1_s11 ALSO IN DsTestServerPool;
PROCESSOR Proc_m1_s19 ALSO IN DsTestServerPool;
PROCESSOR Proc_m1_s21 ALSO IN DsTestServerPool;


ENVIRONMENT DATA

DsTest_disableClientProcess= "1"
DsTest_distributeServerPortsOnAllProcessors= "0"
DsTest_useOneSessionServerPerPort= "0"
DsTest_delayBetweenServerRestartsOnPort= "0"
DsTest_verboseLevel="0"

ENDDATA

-    -    -    -    -

File Envsettings:

# Include VIP test program
epconfig s -r /home/dicostest/systest/test_programs/vipTest/DsSocket_IDP
epconfig s -r /home/dicostest/systest/test_programs/vipTest/dsSocket/DicosServerProcess_LM


VIP settings for e.g. to28 in /opt/telorb/etc/telorb.conf
---------------------------------------------------------

vip-network vipnet0 192.168.76.0
vip-network vipnetmask0 255.255.255.0

vip-network vipnet1 192.168.77.0
vip-network vipnetmask1 255.255.255.0

vip_dicosProc_m0_s17_2 ip_addr_for_vip0 192.168.76.80
vip_dicosProc_m0_s17_2 eth_addr_for_vip0 00:80:37:8f:34:88

vip_dicosProc_m0_s17_3 ip_addr_for_vip1 192.168.77.80
vip_dicosProc_m0_s17_3 eth_addr_for_vip1 00:80:37:8f:34:89

vip_dicosProc_m0_s19_2 ip_addr_for_vip0 192.168.76.81
vip_dicosProc_m0_s19_2 eth_addr_for_vip0 00:80:37:8f:34:26

vip_dicosProc_m0_s19_3 ip_addr_for_vip1 192.168.77.81
vip_dicosProc_m0_s19_3 eth_addr_for_vip1 00:80:37:8f:34:27


Start the VIP test program for e.g. to28
----------------------------------------
ssh telorb@ulinpc52          (or use 134.138.184.175)

cd /home/telorb/viptest

more to28_env_dicos
  #setenv DsTest_numOfMessages 100
  #setenv DsTest_delayBetweenPortsConnection 100
  #setenv DsTest_portsBase 12345
  #setenv DsTest_host 134.138.71.24

  export DsTest_numOfMessages="100"
  export DsTest_delayBetweenPortsConnection="1000"
  export DsTest_portsBase="12345"
  export DsTest_host="134.138.71.28"
  export DsTest_message="hejhopp to28"
  export DsTest_verboseLevel="0"

  #export DsTest_delayBetweenServerRestartsOnPort="10"
  #export DsTest_message=`cat /etc/squid/squid.conf`
  #export DsTest_message="hejhopp"
  #export DsTest_verboseLevel="1"
  #export DsTest_numberOfClientInstances="3"

more to28_env_linux
  #setenv DsTest_numOfMessages 100
  #setenv DsTest_delayBetweenPortsConnection 100
  #setenv DsTest_portsBase 12453
  #setenv DsTest_host 134.138.71.24

  export DsTest_numOfMessages="100"
  export DsTest_delayBetweenPortsConnection="1000"
  export DsTest_portsBase="12453"
  export DsTest_host="134.138.71.28"
  export DsTest_message="hejhopp to28"
  export DsTest_verboseLevel="0"

  #export DsTest_delayBetweenServerRestartsOnPort="10"
  #export DsTest_message=`cat /etc/squid/squid.conf`
  #export DsTest_message="hejhopp"
  #export DsTest_verboseLevel="1"
  #export DsTest_numberOfClientInstances="3"

source to28_env_dicos                   (Source the valid environment for Dicos)

./DsTestUnixClient.LM_DSS3.R1A04.i486-Redhat-6.0  (Start VIP test program)

Same procedure for Linux in another window.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Parameter "alias"
 (Updated: 2002-04-04 for R14-Linux EarlyDrop3.2)

The alias parameter is not yet handled in the communication to external routers.
However, alias works fine for loopback addresses.
An example for a loopback solution would be:

i4ddCommand_300 = "ddconfig i4dd0 Proc_m0_s9:eth0:172.16.100.101
  Proc_m0_s9:eth1:172.17.100.101 Proc_m0_s11:eth0:172.16.100.101
  Proc_m0_s11:eth1:172.17.100.101"

i4ddCommand_310 = "ifconfig i4dd0 inet 101.101.101.1
i4ddCommand_330 = "route add default -interface i4dd0"
i4ddCommand_340 = "ddconfig i4dd1"
i4ddCommand_350 = "ifconfig i4dd1 inet 192.168.63.100 alias
  192.168.63.101 alias 192.168.63.102  alias 192.168.63.105 alias
  192.168.63.106 alias 192.168.63.108"

(i4ddCommand_320 = "route delete default" is no longer needed.)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Initial data and processor configuration
 (Updated: 2001-06-04) (Information may be outdated)

In order to enable Distributed IP, some configuration is needed in the INITIAL
DATA part of epct.

The structure of the data follows the method used by the filesystem. I.e. a
CommandPrefix together with an incrementing number is assigned a command string
to be executed by a command interpreter.

The Command prefix is i4ddCommand_  (where i4dd is short for IP version 4
distributor device).

The main use for this command is to create and configure the IP version 4
distributor device(s).

The commands supported are ddconfig, ifconfig and route.

ddconfig is used to create a distributor device, the device will be created on
all processors (in DicosCommon_Pool).
The format of the ddconfig command is:
 ddconfig DEVICENAME
 [ProcessorName:PhysicalDeviceName:Ipv4AddrOfGateway]....

The DEVICENAME must start with i4dd and end with an instance id.
Then follows the 'next gateway' tripplets, each parameter in the tripplet is
separated by a colon.
The triplet is used by the distributor device when forwarding messages.
It describes a way out to a router.

Example:
  i4ddCommand_0 = "ddconfig i4dd0 Processor1:eth2:192.168.100.1 Processor2:eth2:192.168.100.5"

A distributor device is created with the name i4dd0. It is the instance 0.
It has two ways out, one is through processor 1 ethernet 2 towards gateway
192.168.100.1. The other way is through Processor 2 ethernet 2 towards
gateway 192.168.100.5.

ifconfig is used to tie a device to the IP stack, in this case it is used to
bind the distributor devices to the IP stack.
The format of the ifconfig command is:
 ifconfig DEVICENAME inet IPADDRESS

Example:
  i4ddCommand_1 = "ifconfig i4dd0 inet 134.138.125.22"

Here we bind the newly created i4dd device 'i4dd0' to the ip address
134.138.125.22. The address 134.138.125.22 will be a VIP address towards the
TelORB cluster.

The route command is used to define where the IP stack will send outgoing
messages.

There are many arguments to route, but the most common one is to add a default
route, e.g.
 i4ddCommand_2 = "route add default -interface  i4dd0"

This command tells the IP stack to forward all traffic for which it has no
specific route towards the i4dd0 interface.

(Source: E-mail from Anders Fransén, 2001-06-11)

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

Example of VIP set up:

                                                         EthA  EthB
                                                            |  |
                                                     ---    |  |
                                   -----------------| V |   |  |
                                  /    192.168.63.2 | I |---O  |
                                 /                  | P |   |  |
                                /                   |   |   |  |
                               /                    | T |------O    ---
                              /    -----------------| P |   |  |   |   |
 ---                         /    /    192.168.64.2  ---    O------|   |
(   )          192.168.63.1 /    /                          |  |   | T |
( W ) Ethernet    -------- / 192.168.63.5            ---    |  |   | P |
(   )------------| ROUTER |----/--------------------| V |   |  O---|   |
( O ) VIP addr    -------- \  /        192.168.63.6 | I |---O  |   |   |
(   )          192.168.63.9 \/                      | P |   |  |    ---
( R )          192.168.64.1 /\                      |   |   |  |
(   ) Ethernet    -------- / 192.168.64.5           | T |------O    ---
( L )------------| ROUTER |----\--------------------| P |   |  |   |   |
(   ) VIP addr    -------- \    \      192.168.64.6  ---    O------|   |
( D )          192.168.64.9 \    \                          |  |   | T |
(   )                        \    \                  ---    |  |   | P |
 ---                          \    -----------------| V |   |  O---|   |
                               \      192.168.63.10 | I |---O  |   |   |
DIP =                           \                   | P |   |  |    ---
Distributed                      \                  |   |   |  |
IP stack                          \                 | T |------O
                                   -----------------| P |   |  |
2 VIP interfaces on each VIP TP       192.168.64.10  ---    |  |
TP = TelORB Processor                                       |  |

192.168.63.0 = VIP net 1
192.168.63.1 = IP address of router connection
192.168.63.2 = IP address of VIP_A connection on TP board
192.168.63.3 = Broadcast address for VIP net 1

192.168.63.4 = VIP net 2
192.168.63.5 = IP address of router connection
192.168.63.6 = IP address of VIP_A connection on TP board
192.168.63.7 = Broadcast address for VIP net 2

192.168.63.8 = VIP net 3
192.168.63.9 = IP address of router connection
192.168.63.10 = IP address of VIP_A connection on TP board
192.168.63.11 = Broadcast address for VIP net 3

192.168.64.0 = VIP net 4
192.168.64.1 = IP address of router connection
192.168.64.2 = IP address of VIP_B connection on TP board
192.168.64.3 = Broadcast address for VIP net 4

192.168.64.4 = VIP net 5
192.168.64.5 = IP address of router connection
192.168.64.6 = IP address of VIP_B connection on TP board
192.168.64.7 = Broadcast address for VIP net 5

192.168.64.8 = VIP net 6
192.168.64.9 = IP address of router connection
192.168.64.10 = IP address of VIP_B connection on TP board
192.168.64.11 = Broadcast address for VIP net 6


From TelORB and out (to e.g. the router), load sharing is used.
TelORB is prepared for both load sharing and non-load sharing.

From the router and in to TelORB, load sharing and non-load sharing can be used,
depending on how the router is configured. E.g. ECMP on the router enables load
sharing.


MXP64 board with a PMC module with 2 interfaces:
 ---
|   |
| X |  Eth2or3
| X |  Eth2or3
|   |
| X |  Eth0  (PMC module) (Connect to EthA) (On serial terminal when disconnected: "eth0: link down")
| X |  Eth1  (PMC module) (Connect to EthB) (On serial terminal when disconnected: "eth1: link down")
 --- 

Example of VIP INITIAL DATA configuration in the epct file for TelORB system
to20 (two TelORB processors (P8 and P16) used for VIP addressing and one VIP
address):
  # VIP addressing
  # Define all VIP nets (use internal IP addresses)
  i4ddCommand_0 = "ddconfig i4dd0 Processor8:eth0:192.168.63.1 Processor16:eth0:192.168.63.5"
  # Define VIP addresses (use IP addresses from own TelORB system + 2, e.g. use
  # to22 addresses for to20, start with 10 for lower net part and 240 for higher
  # net part)
  i4ddCommand_1 = "ifconfig i4dd0 inet 134.138.59.10"
  //i4ddCommand_2 = "route add -net 192.168.135.0/24 -interface i4dd0"
  # Delete default router set by dhcpd.pxe.conf
  i4ddCommand_2 = "route delete default"
  # Define VIP address as default router
  i4ddCommand_3 = "route add default -interface i4dd0"
  //i4ddCommand_4 = "route add -host 192.168.130.25 -interface lo0"
  # Set up VIP firewall, 17=UDP/IP, 6=TCP/IP, 0=completely open
  SocketUserDistributionCfg_0 = "0x800:17:0:roundRobinDistributor"
  SocketUserDistributionCfg_1 = "0x800:6:0:roundRobinDistributor"

The data above shows that the selected VIP address of the TelORB cluster is
134.138.59.10.

Example of TelORB processor configuration in the epct file for TelORB system
to20 (two TelORB processors (P8 and P16) used for VIP addressing):
    :
  PROCESSOR Processor8 
	  TARGET i486 
	  TYPE IntelPc 
	  ADDRESS "00:a0:a5:3a:00:b2 00:a0:a5:3a:00:b3" 
	  IN DicosCommonPool;
    :
  PROCESSOR Processor16 
        TARGET i486 
        TYPE IntelPc 
          ADDRESS "00:a0:a5:3a:00:ac 00:a0:a5:3a:00:ad" 
          IN DicosCommonPool;
    :
 
IP addresses fetched from the bootstrap loader part when resetting a MXP64
TelORB processor with a PMC interface with 2 connections (altogether 4
connections, i.e. EthA, EthB, VIP_A and VIP_B):
  Found DEC21142 at I/O 0xd000, IRQ 12, ethernetAddress = 00:30:f7:01:a9:2c
  Driver eth0 published
  Found DEC21142 at I/O 0xd400, IRQ 5, ethernetAddress = 00:30:f7:01:a9:2d
  Driver eth1 published
  Driver bsdEnv published
  Found SB82557 at I/O 0xe400, IRQ 5, ethernetAddress = 00:a0:a5:3a:00:ac
  Driver eth2 published
  Found SB82557 at I/O 0xe800, IRQ 10, ethernetAddress = 00:a0:a5:3a:00:ad
  Driver eth3 published

eth0 will be the VIP_A address.
eth1 will be the VIP_B address.
eth2 will be the EthA address.
eth3 will be the EthB address.

( Example of a bootstrap loading of a TelORB processor with only two ethernet
  connections:
    Found DEC21142 at I/O 0xe400, IRQ 12, ethernetAddress = 00:30:f7:00:e5:17
    Driver eth0 published
    Driver Inet published
    Found SB82557 at I/O 0xe800, IRQ 10, ethernetAddress = 00:a0:a5:2d:02:81
    Driver eth1 published )

== == == == == == == == == == == == == == == == == == == == == == == == == ==

dhcpd.pxe.conf configuration
 (Updated: 2001-06-04) (Information may be outdated)

Define the VIP nets (in this example there are two VIP nets):

     :
   subnet 192.168.63.0 netmask 255.255.255.252 {
   }

   subnet 192.168.64.0 netmask 255.255.255.252 {
   }

   subnet 192.168.63.4 netmask 255.255.255.252 {
   }

   subnet 192.168.64.4 netmask 255.255.255.252 {
   }

   option dumpServerAddress    134.138.64.26, 134.138.63.25;   (non-VIP setting)
     :

     :
host p8_0 {
   hardware ethernet 00:a0:a5:3a:00:b2;
   fixed-address     134.138.63.38;
}

host p8_1 {
   hardware ethernet 00:a0:a5:3a:00:b3;
   fixed-address     134.138.64.38;
}

host p8_2 {
   hardware ethernet 00:30:f7:01:a9:38;
   fixed-address     192.168.63.2;
}

host p8_3 {
   hardware ethernet 00:30:f7:01:a9:39;
   fixed-address     192.168.64.2;
}
     :
host p16_0 {
   hardware ethernet 00:a0:a5:3a:00:ac;
   fixed-address     134.138.63.46;
}

host p16_1 {
   hardware ethernet 00:a0:a5:3a:00:ad;
   fixed-address     134.138.64.46;
}

host p16_2 {
   hardware ethernet 00:30:f7:01:a9:2c;
   fixed-address     192.168.63.6;
}

host p16_3 {
   hardware ethernet 00:30:f7:01:a9:2d;
   fixed-address     192.168.64.6;
}
     :

When using the telorb.conf file to set up the VIP configuration (in addition to
the ordinary definition of the TelORB processor MAC addresses in the telorb.conf
file):
     :
internal-network subnet2 192.168.63.0
internal-network netmask2 255.255.255.252

internal-network subnet3 192.168.64.0
internal-network netmask3 255.255.255.252

internal-network subnet4 192.168.63.4
internal-network netmask4 255.255.255.252

internal-network subnet5 192.168.64.4
internal-network netmask5 255.255.255.252

dicosprocessor8_2 eth_addr_for_eth2 00:30:f7:01:a9:38
dicosprocessor8_2 ip_addr_for_eth2 192.168.63.2

dicosprocessor8_3 eth_addr_for_eth3 00:30:f7:01:a9:39
dicosprocessor8_3 ip_addr_for_eth3 192.168.64.2

dicosprocessor16_2 eth_addr_for_eth2 00:30:f7:01:a9:2c
dicosprocessor16_2 ip_addr_for_eth2 192.168.63.6

dicosprocessor16_3 eth_addr_for_eth3 00:30:f7:01:a9:2d
dicosprocessor16_3 ip_addr_for_eth3 192.168.64.6
     :


telorb.conf info for TSP 4.0 Clusterware & OS (2001-10-25):
vip-network vipnet0 192.168.63.0
vip-network vipnetmask0 255.255.255.252
vip_dicosprocessor1_2 eth_addr_for_vip0 00:80:37:8f:33:ae
vip_dicosprocessor1_2 ip_addr_for_vip0 192.168.63.2

vip-network vipnet1 192.168.64.0
vip-network vipnetmask1 255.255.255.252
vip_dicosprocessor1_3 eth_addr_for_vip1 00:80:37:8f:33:af
vip_dicosprocessor1_3 ip_addr_for_vip1 192.168.64.2

vip-network vipnet2 192.168.63.4
vip-network vipnetmask2 255.255.255.252
vip_dicosprocessor6_2 eth_addr_for_vip2 00:80:37:8f:34:88
vip_dicosprocessor6_2 ip_addr_for_vip2 192.168.63.6

vip-network vipnet3 192.168.64.4
vip-network vipnetmask3 255.255.255.252
vip_dicosprocessor6_3 eth_addr_for_vip3 00:80:37:8f:34:89
vip_dicosprocessor6_3 ip_addr_for_vip3 192.168.64.6

vip-network vipnet4 192.168.63.8
vip-network vipnetmask4 255.255.255.252
vip_dicosprocessor7_2 eth_addr_for_vip4 00:80:37:8f:34:26
vip_dicosprocessor7_2 ip_addr_for_vip4 192.168.63.10

vip-network vipnet5 192.168.64.8
vip-network vipnetmask5 255.255.255.252
vip_dicosprocessor7_3 eth_addr_for_vip5 00:80:37:8f:34:27
vip_dicosprocessor7_3 ip_addr_for_vip5 192.168.64.10

vip-network vipnet6 192.168.63.12
vip-network vipnetmask6 255.255.255.252
vip_dicosprocessor10_2 eth_addr_for_vip6 00:80:37:5e:ff:98
vip_dicosprocessor10_2 ip_addr_for_vip6 192.168.63.14

vip-network vipnet7 192.168.64.12
vip-network vipnetmask7 255.255.255.252
vip_dicosprocessor10_3 eth_addr_for_vip7 00:80:37:5e:ff:97
vip_dicosprocessor10_3 ip_addr_for_vip7 192.168.64.14

General
 (Updated: 2003-10-13)

Excerpt from "DicosSyslogClient (OU/D61, LM/D35)" (syslog):
    "The DicosSyslog was introduced in TSP4 AD11 and is intended to be a better
     alternative for logging than the console printouts.
     One big improvement compared to the console printouts is that the
     DicosSyslog is common for the entire node, not per-processor as for
     the console printouts. 
     The DicosSyslogClient should run on an external processor, usually
     the IO machines, and is responsible for collecting the DicosSyslog
     messages from all TelORB processors. Many (up to 5 in AD 11)
     DicosSyslogClient may be connected to a single TelORB system."

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Restart the syslog located in /var/log/
 (Updated: 2003-10-13)

  su
  /etc/initd.syslog restart

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Verification of syslog
 (Updated: 2003-10-13)

Verify that the following TelORB processor types can write to the syslog:
- Dicos processor - loader
- Dicos processor - non loader
- Linux processor   (always loader)

Check the messages written to the syslog by entering the following command on
both IO processors:
  tail -f /opt/telorb/syslog

The processor name is the first entry in each message.
Verify that all processor types are writing to the syslog, by performing the
action(s) below.

To trigger all Dicos (loaders and non loaders) processors to write to the
syslog, just disable or reload one Dicos processor.

To trigger Linux processors to write to the syslog is not as simple as for the
Dicos processors. One way to check that a Linux processor can write to the
syslog is to do the following:

- Log in to a Linux processor from one of the IO processors (as user telorb):
    telnet -l telorb 172.16.100.123  (Adjust IP address)
       or
    ssh -l telorb 172.16.16.9        (Adjust IP address)
    Password: <psw>
- Change the user to root 
    su
- Goto /tmp
    cd /tmp
- Generate a message to the syslog
    echo SYSLOG_TEST > DicosSyslog_fifo
- The processor name followed by the string "SYSLOG_TEST" should appear in the
  syslog.

Stop the tail command on both IO processors:
  Ctrl-c

== == == == == == == == == == == == == == == == == == == == == == == == == ==

How to use the Syslog
 (Updated: 1999-12-10. Verbal information from Lars Ekman)

From new shell:
uabs31i1c47% ~dicoshack/Hack/uablrek/bin/DicosSyslogClient.sparc -z 800 -t 134.138.70.101-107
Accepted from processorNo = 7
Accepted from processorNo = 4
Accepted from processorNo = 5
Accepted from processorNo = 6
Accepted from processorNo = 1
Accepted from processorNo = 2
Accepted from processorNo = 3
TelORB: Fri Dec 10 13:44:59 1999,  Host: Fri Dec 10 13:44:55 1999
 1 [ +311] SYSLOG: New Monitoring Client: 134.138.186.47:39736 "DicosSyslogClient"
^C
uabs31i1c47% ~dicoshack/Hack/uablrek/bin/DicosSyslogClient.sparc -z 800 -t 134.138.70.101-107 | tee dicossyslog
^C
uabs31i1c47% ~dicoshack/Hack/uablrek/bin/DicosSyslogClient.sparc -z 800 -t 134.138.70.101-107 
Accepted from processorNo = 6
Accepted from processorNo = 7
Accepted from processorNo = 1
Accepted from processorNo = 2
Accepted from processorNo = 3
Accepted from processorNo = 4
Accepted from processorNo = 5
TelORB: Fri Dec 10 13:46:51 1999,  Host: Fri Dec 10 13:46:46 1999
 1 [ +194] SYSLOG: New Monitoring Client: 134.138.186.47:39750 "DicosSyslogClient"
^C
uabs31i1c47% ~dicoshack/Hack/uablrek/bin/DicosSyslogClient.sparc -z 800 -t 134.138.70.101-107 -L > dicossyslog 
^Z
Suspended
uabs31i1c47% bg
[1]    ~dicoshack/Hack/uablrek/bin/DicosSyslogClient.sparc -z 800 -t  ... &
uabs31i1c47% ~dicoshack/Hack/uablrek/bin/DicosSyslogClient.sparc -z 800 -t 134.138.70.101-107 
Accepted from processorNo = 7
Accepted from processorNo = 1
Accepted from processorNo = 2
Accepted from processorNo = 3
Accepted from processorNo = 4
Accepted from processorNo = 5
Accepted from processorNo = 6
TelORB: Fri Dec 10 13:47:29 1999,  Host: Fri Dec 10 13:47:26 1999
 1 [ +677] SYSLOG: New Monitoring Client: 134.138.186.47:39764 "DicosSyslogClient"

From new shell:
uabs31i1c47% telnet 172.16.0.9 8000       (Adjust 8000 to be valid for the
                                           processor which you are logging into)
                                          (Old IP: telnet 134.138.70.101 8000)
Trying 134.138.70.101...
Connected to 134.138.70.101.
Escape character is '^]'.
TelORB shell - welcome

$ /> cd env

$ /env> ls
printenv*
getenv*
setenv*
unsetenv*

$ /env> printenv

$ /env> cd ..

$ /> cd syslog

$ /syslog> ls
loglevel*
echolevel*

$ /syslog> echolevel 7

$ /syslog> echolevel
No level given! (Valid range 1-7)
  -or-
$ /syslog> echolevel                        (Check which level that is valid)
5

$ /syslog> loglevel 7

$ /syslog> echolevel 7

$ /syslog> 

There are 8 levels (0-7).
Level 5 is default.
Level 0 = reload.
Level 7 = debug printouts.       (Will appear in the TelORB processor log files)

General
 (Updated: 2004-02-02)

The file DicosNotificationTypes.h contains a list of all valid CW/OS
notifications, which can be sent from Dicos (TelORB) in the TSP system.
This list can be useful when e.g. looking in the TelORB processor logs or in the
syslog (/opt/telorb/syslog on the IO processors).
These logs do not contain the slogan of notifications, only the notification
types (e.g. 3). It can therefore be hard to determine what kind of notifications
the logs contains.

Here is an example of how a notification may appear in the syslog:
  "Proc_m1_s9 [ +521] NOTIFICATION: [type=3, objectType=Processor,
   instance=Proc_m0_s5, notificationId=16, time=2004-1-20 17:13:21]"
This shows that notification "Processor reload failed" (type=3) has been
received (see list of notification types below).

Here is an example of where to find the DicosNotificationTypes.h file (adjust
the path to suit the release which is valid for you):
  more /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/
       TelORB-R15-LSV506/TelORB-R15-LSV506-SDK/system/TelORB/
       CXA_1100928_1_R1A01-TelORB_Management_API/included/
       SWI_D182-NotificationNumbers/incl/DicosNotificationTypes.h

== == == == == == == == == == == == == == == == == == == == == == == == == ==

List of notification types for Dicos in TSP 5.0
 (Updated: 2004-02-02)

#define	NPROCRELOADSTARTED	1	/* Processor reload started */
/* NotificationInfo:  
   notificationType: 1
   objectType = "Processor"
   instance = <processor name>
*/

#define	NPROCRELOADSUCCEEDED	2	/* Processor reload finished sucessfully */
/* NotificationInfo:  
   notificationType: 2
   objectType = "Processor"
   instance = <processor name>
*/

#define	NPROCRELOADFAILED	3	/* Processor reload failed */
/* NotificationInfo:  
   notificationType: 3
   objectType = "Processor"
   instance = <processor name>
*/

#define	NPLANNEDSTARTED		4	/* Planned re-configuration started */
/* NotificationInfo:  
   notificationType: 4
   objectType = "Processor"
   instance = <processor name>
   attribute [0] = "OPERATION", <supplyWithDUs or moveAllDUs>
*/

#define	NPLANNEDSUCCEEDED	5	/* Planned re-configuration finished sucessfully */
/* NotificationInfo:  
   notificationType: 5
   objectType = "Processor"
   instance = <processor name>
*/

#define	NPLANNEDFAILED		6	/* Planned re-configuration failed */
/* NotificationInfo:  
   notificationType: 6
   objectType = "Processor"
   instance = <processor name>
*/

#define	NUPGRADESTARTED		7	/* System Upgrade started */
/* NotificationInfo:  
   notificationType: 7
   objectType = "upgrade"
   instance = 
   attribute [0] = "NAME", <upgrade package name>
   attribute [1] = "TYPE", <upgrade package type>
*/

#define	NUPGRADESUCCEEDED	8	/* System Upgrade finished sucessfully */
/* NotificationInfo:  
   notificationType: 8
   objectType = "upgrade"
   instance = 
   attribute [0] = "NAME", <upgrade package name>
   attribute [1] = "TYPE", <upgrade package type>
*/

#define	NUPGRADEFAILED		9	/* System Upgrade failed */
/* NotificationInfo:  
   notificationType: 9
   objectType = "upgrade"
   instance = 
   attribute [0] = "NAME", <upgrade package name>
   attribute [1] = "TYPE", <upgrade package type>
*/

#define	NADDPROCSTARTED		10	/* Add processor started */
/* NotificationInfo:  
   notificationType: 10
   objectType = "Processor"
   instance = <processor name>
*/

#define	NADDPROCSUCCEEDED	11	/* Add processor finished sucessfully */
/* NotificationInfo:  
   notificationType: 11
   objectType = "Processor"
   instance = <processor name>
*/

#define	NADDPROCFAILED		12	/* Add processor failed */
/* NotificationInfo:  
   notificationType: 12
   objectType = "Processor"
   instance = <processor name>
*/

#define	NREMOVEPROCSTARTED	13	/* Remove processor started */
/* NotificationInfo:  
   notificationType: 13
   objectType = "Processor"
   instance = <processor name>
*/

#define	NREMOVEPROCSUCCEEDED	14	/* Remove processor finished sucessfully */
/* NotificationInfo:  
   notificationType: 14
   objectType = "Processor"
   instance = <processor name>
*/

#define	NREMOVEPROCFAILED	15	/* Remove processor failed */
/* NotificationInfo:  
   notificationType: 15
   objectType = "Processor"
   instance = <processor name>
*/

#define	NBACKUPSTARTED		16	/* Backup started */
/* NotificationInfo:  
   notificationType: 16
   objectType = "backup"
   instance = 
   attribute [0] = "NAME", <version name>
*/

#define	NBACKUPSUCCEEDED	17	/* Backup finished sucessfully */
/* NotificationInfo:  
   notificationType: 17
   objectType = "backup"
   instance = 
   attribute [0] = "NAME", <version name>
*/

#define	NBACKUPFAILED		18	/* Backup failed */
/* NotificationInfo:  
   notificationType: 18
   objectType = "backup"
   instance = 
   attribute [0] = "NAME", <version name>
   attribute [1] = "ERROR", <error code>
*/

#define	NREMOVEBACKUPSTARTED	19	/* Remove backup started */
/* NotificationInfo:  
   notificationType: 19
   objectType = "backup"
   instance = 
   attribute [0] = "NAME", <version name>
*/

#define	NREMOVEBACKUPSUCCEEDED	20	/* Remove backup finished sucessfully */
/* NotificationInfo:  
   notificationType: 20
   objectType = "backup"
   instance = 
   attribute [0] = "NAME", <version name>
*/

#define	NREMOVEBACKUPFAILED	21	/* Remove backup failed */
/* NotificationInfo:  
   notificationType: 21
   objectType = "backup"
   instance = 
   attribute [0] = "NAME", <version name>
   attribute [1] = "ERROR", <error code>
*/

#define	NUPGRADESCANSUCCESS	22	/* System Upgrade Scan success */
/* NotificationInfo:  
   notificationType: 22
   objectType = "upgrade"
   instance = 
*/

#define	NUPGRADESCANFAILURE	23	/* System Upgrade Scan failure */
/* NotificationInfo:  
   notificationType: 23
   objectType = "upgrade"
   instance = 
*/

#define	NUPGRADEREMOVESUCCESS	24	/* System Upgrade Remove success */
/* NotificationInfo:  
   notificationType: 24
   objectType = "upgrade"
   instance = 
*/

#define	NUPGRADEREMOVEFAILURE	25	/* System Upgrade Remove failure */
/* NotificationInfo:  
   notificationType: 25
   objectType = "upgrade"
   instance = 
*/

#define ONGOINGBACKUPFAILED 26    	/* Handles a processor/process Reload 
					   under an on going  SW Version 
					   backup, if this Notification is send
					   it means that the system is trying
					   to clean up after som missed backup.
					 */
 
/* When a SW Version create is started we saved the name of the on going backup
as a Database object, in case of a processor/process reload this name and flag
is retrive, if this name missmatch the active version this Notification is send 
and the backup is remove authomaticly.

   NotificationInfo:  
   notificationType: 26
   objectType = "backup"
   instance = 
*/

#define	CAPSULEABORTION		27	/* Capsule abortion generated a dump file */
/* NotificationInfo:  			 Rev 1.5  uabtors 			  
   notificationType: 27
   objectType = "DicosDriver_00XX00YY"
   instance = "TftpDumpDriver"
   attr[0] = "CapsuleDump : ","DicosTextDump"

*/

#define	NENABLEPROCSTARTED	28	/* Enable processor started */
/* NotificationInfo: 		  
   notificationType: 28
   objectType = "Processor"
   instance = <processor name>
*/

#define	NENABLEPROCSUCCEEDED	29	/* Enable processor succeeded */
/* NotificationInfo: 		  
   notificationType: 29
   objectType = "Processor"
   instance = <processor name>
*/

#define	NENABLEPROCFAILED	30	/* Enable processor failed */
/* NotificationInfo: 		  
   notificationType: 30
   objectType = "Processor"
   instance = <processor name>
*/

#define	NDISABLEPROCSTARTED	31	/* Disable processor started */
/* NotificationInfo: 		  
   notificationType: 31
   objectType = "Processor"
   instance = <processor name>
*/

#define	NDISABLEPROCSUCCEEDED	32	/* Disable processor succeeded */
/* NotificationInfo: 		  
   notificationType: 32
   objectType = "Processor"
   instance = <processor name>
*/

#define	NDISABLEPROCFAILED	33	/* Disable processor failed */
/* NotificationInfo: 		  
   notificationType: 33
   objectType = "Processor"
   instance = <processor name>
*/

#define	RBACKUPSTARTED	34	/* Reactivation of backup Started. */
/* NotificationInfo:  
   notificationType: 34
   objectType = "backup"
   instance = 
*/

#define	RBACKUPSUCCEEDED	35    /* Reactivation of backup Done OK. */
/* NotificationInfo:  
   notificationType: 35
   objectType = "backup"
   instance = 
*/

#define	RBACKUPFAILED	36	/* Reactivation of backup failed */
/* NotificationInfo:  
   notificationType: 36
   objectType = "backup"
   instance = 
*/

#define	NLOSTDEFAULTROUTER	37    /* Lost default router. */
/* NotificationInfo:  
   notificationType: 37
   objectType = "DefaultRouterPinger"
   instance = DefaultRouterPinger
*/

#define	NFOUNDDEFAULTROUTER	38	/* Found default router */
/* NotificationInfo:  
   notificationType: 38
   objectType = "DefaultRouterPinger"
   instance = DefaultRouterPinger
*/

#define	NEXTSYNCHSTARTED	39	/* External synch started */
/* NotificationInfo:  
   notificationType: 39
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
*/

#define	NEXTSYNCHSUCCEEDED	40	/* External synch succeeded */
/* NotificationInfo:  
   notificationType: 40
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
   attribute [2] = "InstalledObjects", <created objects minus deleted objects>
   attribute [3] = "UpdatedObjects", <number of updated objects>
*/

#define	NEXTSYNCHFAILED 	41	/* External synch failed */
/* NotificationInfo:  
   notificationType: 41
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
   attribute [2] = "InstalledObjects", <number of created objects minus number of deleted objects>
   attribute [3] = "UpdatedObjects", <number of updated objects>
*/

#define NREMOTESYNCHSTARTED     42      /* Remote synch started */
/* NotificationInfo:  
   notificationType: 42
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/

#define NREMOTESYNCHSUCCEEDED    43      /* Remote synch finished successfully */
/* NotificationInfo:  
   notificationType: 43
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "NoOfDifferingObjects", <number of differing objects>
*/

#define NREMOTESYNCHREQUIRESEXTSYNCH      44      /* Remote synch requires external synch */
/* NotificationInfo:  
   notificationType: 44
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [2] = "BackupName", <backup name>
*/

#define NREMOTESYNCHFAILED      45      /* Remote synch failed */
/* NotificationInfo:  
   notificationType: 45
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/

#define DICOSAPPLOG_NT	46
/* NotificationInfo: 1
   notificationType: 46
   objectType = "DicosDriver"
   instance = "DicosApplogDriver"
   attribute [0] = "NACKs since last Notification", <count>
*/

#define TRANSFERSTARTED  47      /* Transfer started */
/* NotificationInfo:
   notificationType: 47
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
*/

#define TRANSFERFINISHED  48      /* Transfer finished */
/* NotificationInfo:
   notificationType: 48
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
*/

#define TRANSFERTIMEOUT  49      /* Transfer timeout */
/* NotificationInfo:
   notificationType: 49
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
*/

#define TRANSFERFAILED  50      /* Transfer failed */
/* NotificationInfo:
   notificationType: 50
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
*/

#define TRANSFERIGNORED  51      /* Transfer ignored */
/* NotificationInfo:
   notificationType: 51
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "BackupName", <backup name>
*/                                                                                                                                            
#define RECONCILIATIONSTARTEDASPRIMARY  52      /* Reconciliation Started as Primary */
/* NotificationInfo:
   notificationType: 52
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/                                                                                                                                            

#define RECONCILIATIONSTARTEDASSTANDBY  53      /* Reconciliation Started as Standby */
/* NotificationInfo:
   notificationType: 53
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/

#define RECONCILIATIONFINISHEDASPRIMARY  54     /* Reconciliation Finished as Primary */
/* NotificationInfo:
   notificationType: 54
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/

#define RECONCILIATIONFINISHEDASSTANDBY  55     /* Reconciliation Finished as Standby */
/* NotificationInfo:
   notificationType: 55
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/

#define RECONCILIATIONFAILEDASPRIMARY  56     /* Reconciliation Failed as Primary */
/* NotificationInfo:
   notificationType: 56
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/
 
#define RECONCILIATIONFAILEDASSTANDBY  57     /* Reconciliation Failed as Standby */
/* NotificationInfo:
   notificationType: 57
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
*/

#define RECONCILIATIONDELAYEDONPRIMARY  58     /* Reconciliation Delayed on Primary */
/* NotificationInfo:
   notificationType: 58
   objectType = "networkRedundancy"
   instance = "traffic"
   attribute [0] = "PeerZoneId", <peer zone id>
   attribute [1] = "DelayTime", <peer zone id>                                                                                               
*/

(Source: E-mail from Krister Nilsson, 2004-01-30, modified by Michel)

Start of DBN DiskLog
 (Updated: 2005-06-03 with input from TACOS TCid 01.010)

The DBN DiskLogging functionality is available in TSP 4 and TSP 5.0, but has
been removed in TSP 5.1 due to robustness problems.
However, it is scheduled to be implemented in a later release, but it is not
yet decided in which release.

The following information is valid for TSP 4 and TSP 5.0.

1. Build with disklog.epct which looks like this:

   For TSP 4:

     SOFTWARE         
             IDP/D24;        // DiskLog

   or for TSP 5.0:

     SOFTWARE 
             CXP901304/1;   // DiskLog_IDP, DBN disk logging

2. Create a backup.

3. Select the Disklog card in the Telorb Manager.

4. Click the "Set" button.
   Set 2 loggers, "OK".
   Verify setting with "Refresh".

5. Click the "Refresh" button in File sets.
   Mark loadingGroup01_1 and click the "Dont Ignore" button.
   Mark loadingGroup01_2 and click the "Dont Ignore" button. (Not for TSP 5.0)
   (This must be done even if it looks like it is already done).

6. Click the "Add" button.
   Set Class Id 524600 for DemoApp or 524308, 524309 (and 10001, to make OP4
   traffic work) for Demo2000, click "OK".
   Verify settings with "Refresh".

7. Click the "Enable" button.
   Verify with "Refresh Status".

8. Click the "Install Log Map" button.

9. Start low intensity traffic, e.g. DemoApp with call window 2.
   Logfiles on IO processors loadingGroup01_1/logs/backupname/
   for TSP 4 and loadingGroup01_1/dbnlogs/backupname/ for TSP 5.0.

10. Create a backup.
    When performing a zone reload, the disklogged transactions are read and
    committed after reload.

Note: If disklogging is left on, the IO processor disks may get full, so if
      disklogging should not be used, reload from first backup where DBN DiskLog
      was not started.

(Source: E-mail from Ola Jönsson, 2001-07-06, modified and text added
by Michel)

General
 (Updated: 2002-12-13)

TIPC is a protocol which handles the communication between processes and
processors in TelORB.
TIPC has efficient intra cluster communication features and good support for
inter cluster communication.
TIPC is used instead of TCP/IP, since TCP/IP does not fulfil the TelORB
requirements.

To get more information about TIPC and the TIPC source code, goto
http://www.lmc.ericsson.se/lmc_j/telorb/tipc/.

Detailed instructions can be found below the section for Shortcut instructions.

Concepts:
  "IO processor software package" is the same as "IO tools package" and is
   delivered in a file called `tools.CXP901305.<version>.tar' which can
   be found in the runtime distribution below system/unix/, e.g.
     /ipims_dicos/ipims_dicos10/dists/TSP4.0-patch/official/
     TelORB-R14-Linux-Patch5/ TelORB-R14-Linux-Patch5-Runtime/system/unix/.
   The IO tools package is not available in the testbed (?).

Shortcut instructions Prerequisites: - You must know the location from where to fetch the new IO tools package, i.e. the tools.CXP901305.<version>.tar file. - It is also a good idea to prepare the IO processor configuration file /opt/telorb/etc/telorb.conf, if not already done. The telorb.conf file should be prepared according to one of the standardized telorb.conf template files which reflect the GEM hardware configurations, e.g. r14_linux_maxi_zone1.telorb.conf.template. The template files are located at /opt/telorb/codearchive/iom_scripts/ on the IO processors. The final version of telorb.conf must always be placed below /opt/telorb/etc/ on both IO processors. Select the valid section below (A, B or C) and perform the instructions on both IO processors (either on both IO processors simultaneously or one after the other). These instructions are also valid for downgrading the IO tools package to an earlier version within JAP 3 or TSP 4, respectively. A) Upgrading the IO tools package from current version to a newer version Use this option when you want to upgrade the IO processor software.) This often results in that section B also has to be executed, due to that the changes to the IO tools package may be in any of the basic tools load modules and in this case the installation procedure (B) has to be executed. B) Installing the IO tools package as new Use this option, for example, when installing the IO tools package on a new IO processor. C) Reconfiguring all running TelORB services Use this option, for example, when you have made changes to the IO processor configuration file `telorb.conf' or when adding/removing TelORB processor(s) to/from the system. A) Upgrading the IO tools package from current version to a newer version 1. Log in to the IO processor as telorb user: ssh telorb@toXioY (Adjust toXioY to valid IO processor name or use its IP address) psw (Type telorb password) 2. Check current IO tools package version (for reference reasons): more /opt/telorb/codearchive/version 3. Fetch the IO tools package file to /opt/telorb/ on the IO processor: id (if not telorb user, do `su telorb') cd /opt/telorb/ ftp 134.138.186.xx (Adjust 134.138.186.xx to valid workstation to fetch the tools package via) telorb (Log in as telorb user) psw (Type telorb password) Go to where the tools.CXP901305.<version>.tar file is going to be fetched from. Special requirements may apply. E.g. when testing a patch or an emergency patch, see Patch testing instructions for R14-Linux (TSP 4.0), point 11 ("Upgrade the IO tools package, if required") for further info. Example for TSP 4.0: cd /ipims_dicos/ipims_dicos10/dists/TSP4.0-patch/official/ TelORB-R14-Linux-Patch5/TelORB-R14-Linux-Patch5-Runtime/system/unix/ Example for TSP 5.0: cd /ipims_dicos/ipims_dicos10/dists/TSP5.0_no_official_use/ TelORB-R15-LSV508.1/TelORB-R15-LSV508.1-Runtime/system/unix/ bin (Not necessary) ls (Check the size of the tools file) get tools.CXP901305.<version>.tar bye For live systems, the following should also be performed, but this is not necessary at the EAB CW/OS lab: Copy the fetched tools.CXP901305.<version>.tar file to directory /opt/OS/tar/ and relink the existing tools.tar file to it: su root cp -a tools.CXP901305.<version>.tar /opt/OS/tar/ ln -s tools.CXP901305.<version>.tar tools.tar exit (The reason for this is if this IO processor will be used to kickstart the other IO processor, the correct tools package will be used.) Only for testing purposes, if an earlier tools package exists (only necessary to perform this on one of the IO processors): Compare the old and the new tools packages to verify that only the IDPs/LMs that have been changed are included in the diff result: tar -tf /opt/telorb/tools.CXP901305.<old_version>.tar > tools_<old_version>.txt tar -tf /opt/telorb/tools.CXP901305.<new_version>.tar > tools_<new_version>.txt diff tools_<old_version>.txt tools_<new_version>.txt > tools_diff.txt less tools_diff.txt (To get a scrolling bar: tar -tf tools.CXP901305.<version>.tar | more) 4. Unpack the fetched tools.CXP901305.<version>.tar file below /opt/telorb/: ls -l (Verify the size of the tools file) tar xf tools.CXP901305.<version>.tar This creates the directory codearchive.CXP901305.<version>. If desired, remove the fetched tools.CXP901305.<version>.tar file: (In the EAB CW/OS lab, do not remove the tar file until you know for sure that it will not be used by you or somebody else in the future.) rm tools.CXP901305.<version>.tar 5. In case you need to revert to the old version of the IO processor software, it is recommended that you save the current software and configuration: cp -r codearchive codearchive_`date '+%b.%d.%Y'` cp -r etc etc_`date '+%b.%d.%Y'` (The /opt/telorb/codearchive/iom_scripts/README file says mv /opt/telorb/codearchive /opt/telorb/codearchive_`date '+%b.%d.%Y'`) 6. Upgrade the IO tools package on the IO processor: cd /opt/telorb/codearchive.CXP901305.<version>/iom_scripts/ ./upgradeTelORB.sh If you do not get any error printouts, the upgrade is completed and you should not continue below. However, if the other IO processor has not yet been upgraded, do so in the same way as when upgrading the first IO processor. If you get the following printouts: "==> It's not possible to perform a simplified upgrade !" "==> Follow section "b) installation" in /README to upgrade the software." you have to follow the instructions in the next section, i.e. B) Installing the IO tools package as new. Start with step 6, since the steps 1-5 have already been performed. B) Installing the IO tools package as new 1. Follow the instructions in step 1 in section A above, if not already done. 2. Follow the instructions in step 2 in section A above, if not already done. 3. Follow the instructions in step 3 in section A above, if not already done. 4. Follow the instructions in step 4 in section A above, if not already done. 5. Follow the instructions in step 5 in section A above, if not already done. 6. Stop the running TelORB services, DHCP server and NFS server (the /opt/telorb/codearchive directory must exist to perform this step): /opt/telorb/etc/stop_services (The /opt/telorb/codearchive/iom_scripts/README file says /etc/rc3.d/S88TelorbServices stop) (If you are running an early version of TelORB R14 without Linux, check if the files S15nfs* and S34Dhcp_isc exist below /etc/rc3.d/. If so, these must be stopped as follows: su root /etc/rc3.d/S15nfs* stop /etc/rc3.d/S34Dhcp_isc stop) 7. Remove the current codearchive directory: cd /opt/telorb/ rm -rf codearchive 8. Move the codearchive, that you previously unpacked, to the default codearchive location: mv /opt/telorb/codearchive.CXP901305.<version> /opt/telorb/codearchive 9. Verify that the new IO tools package version is in the codearchive: more /opt/telorb/codearchive/version 10. Verify that the configuration file telorb.conf exists below directory /opt/telorb/etc/: ls -l /opt/telorb/etc/telorb.conf (Make changes, if necessary) If the file does not exist, it must be created, see Prerequisites above. If the file exists, make sure it is valid. (You should not have to change it, unless you have replaced/changed hardware or if the Delivery Note requests you to.) For live systems, the following should also be performed, but this is not necessary at the EAB CW/OS lab: If the correct version of the telorb.conf file does not exist below directory /opt/OS/, copy it there: cp /opt/telorb/etc/telorb.conf /opt/OS/ (The reason for this is if this IO processor will be used to kickstart the other IO processor, the correct telorb.conf file will be used.) 11. Only valid for the EAB CW/OS lab (to make it possible to use tos1/tos2 later): If not already done, create a copy of the /opt/telorb/etc/exports file, since it will be overwritten when executing the prepareTelORB.sh script below. (The uabexports file will be used in step 13 below). cp /opt/telorb/etc/exports /opt/telorb/etc/uabexports 12. Install and start the new IO tools package services: su root (Enter root mode) psw (Type root password) cd /opt/telorb/codearchive/iom_scripts/ ./prepareTelORB.sh -p -c (or ./prepareTelORB.sh -p -c /opt/telorb/etc/telorb.conf) You will be prompted for which IO processor you are executing on. Enter either: 1 or 2. (If the following question is received "/bin/rm: remove write-protected file `/opt/telorb/.installBackup/...?" then stop the script with Ctrl-c and then enter rm -rf /opt/telorb/.installBackup/* and thereafter re-run the script.) exit (Exit root mode) 13. Only valid for the EAB CW/OS lab (to make it possible to use tos1/tos2 later): Restore the /opt/telorb/etc/exports file to its original content, i.e. the following string should be added at the end of the "/opt/telorb" line in the exports file: 134.138.184.0/255.255.248.0(rw) (See step 11 above) To accomplish this, do as follows: cd /opt/telorb/etc/ cp uabexports exports (If uabexports exists and is valid) or vi exports (Update exports with the EAB CW/OS lab info string) Activate the exports settings by stopping and starting the TelORB services: /opt/telorb/etc/stop_services /opt/telorb/etc/start_services 14. Verify that all TelORB services, DHCP server and NFS server are running: /opt/telorb/etc/status_services 15. Verify that the exports file settings have been activated (this information may also available in the result of the previous status_services command): /usr/sbin/exportfs For the EAB CW/OS lab, verify that the following line exists: /opt/telorb 134.138.184.0/255.255.248.0 16. Only valid for the EAB CW/OS lab: Add EAB CW/OS lab specific "Loadable Extras" to the TelORB Manager to be able to e.g. handle traffic and NetRed: cd /opt/telorb/codearchive/Unix_IDP/included/LM_D115-TelORBManager/jar/ ftp 134.138.186.xx (Adjust 134.138.186.xx to valid workstation to fetch the "Loadable Extras" via) telorb (Log in as telorb user) psw (Type telorb password) There is an unintentional line break in the following cd commands. Each command should be executed as one command line. For TSP 4.0: cd /ipims_dicos/ipims_dicos20/BS2/tbTEST1.3/TEST_IDPG/ TelORBManagerExtras_IDP/TelORBManagerExtras_LM/jar/ For TSP 5.0: cd /ipims_dicos/BS2/tbTEST15.0/TEST_IDPG/ TelORBManagerExtras_IDP/TelORBManagerExtras_LM/jar/ (Adjust tbTEST to valid release) (Previous: cd /ipims_dicos/ipims_dicos20/BS2/tbTEST15.0/TEST_IDPG/ TelORBManagerExtras_IDP/TelORBManagerExtras_LM/jar/) bin get TelORBManagerExtras.jar bye (Another way to add "Loadable Extras" is to do as follows from tos1/tos2: cp /home/dicostest/systest/tsp4.0/TelORB-R14-Linux-upto-patch7.3/ TelORB-R14-Linux-Runtime3.4/examples/ IDP_D28-TelORBManagerExtras-R1A01/included/LM_D116-TelORBManager/ jar/TelORBManagerExtras.jar /toX/toXio1/telorb/codearchive/Unix_IDP/included/ LM_D115-TelORBManager/jar or for TSP5.0: cp /uab/ipims_dicos/ipims_dicos20/BS2/tbTEST15.0/TEST_IDPG/ TelORBManagerExtras_IDP/TelORBManagerExtras_LM/jar/ TelORBManagerExtras.jar /toX/toXio1/telorb/codearchive/Unix_IDP/ included/ LM_D115-TelORBManager/jar (chmod 777 /toX/toXio1/telorb/codearchive/Unix_IDP/included/ LM_D115-TelORBManager/jar/TelORBManager.jar necessary?)) (If you want further information about "Loadable Extras", see Add EAB CW/OS lab specific "Loadable Extras below.) 17. If required, upgrade the software for 3rd Party Products (3PP) as specified in Upgrade the software for 3rd Party Products (3PP) below. 18. Start TelORB processor log files and consoles as specified in Start TelORB processor log files and consoles. 19. If the TelORB Manager is running on the IO processor, disconnect and quit it. (This is done because the new IO tools package may contain a new version of the TelORB Manager.) (Normally, it is enough to start the TelORB Manager on one of the IO processors, preferably on IO1.) Start the TelORB Manager as follows: /opt/telorb/codearchive/iom_scripts/TelORBManager -alarms & 20. If the TelORB processor load viewer is running on the IO processor, close it. (This is done because the new IO tools package may contain a new version of the load viewer.) (Normally, it is enough to start the load viewer on one of the IO processors, preferably on IO1.) Start the load viewer as follows (unintentional line break): /opt/telorb/codearchive/iom_scripts/win -th 172.16.0.9 -th 172.16.8.9 -th 172.16.0.137 -th 172.16.8.137 -n -s & (Adjust IP addresses to valid IP addresses for the Dicos loaders, or in the Linux-only-system-case, for the inital loader and another Linux processor.) The installation/upgrading is now completed. Also install/upgrade the other IO processor, if not already done. C) Reconfiguring all running TelORB services This section is valid when you have made changes to the IO processor configuration file `telorb.conf' or when adding/removing TelORB processor(s) to/from the system. You then have to update the IO processor configuration as follows: 1. Verify that the configuration file telorb.conf exists below directory /opt/telorb/etc/: ls -l /opt/telorb/etc/telorb.conf (Make changes, if necessary) If the file does not exist, it must be created, see Prerequisites above. If the file exists, make sure it is valid. 2. Only valid for EAB CW/OS lab (to make it possible to use tos1/tos2 later): If not already done, create a copy of the /opt/telorb/etc/exports file, since it will be overwritten when executing the configureTelORB.sh script below. (The uabexports file will be used in step 4 below). cp /opt/telorb/etc/exports /opt/telorb/etc/uabexports 3. Reconfigure the IO processor configuration as telorb user: cd /opt/telorb/codearchive/iom_scripts/ ./configureTelORB.sh -c (or ./configureTelORB.sh -c /opt/telorb/etc/telorb.conf) You will be prompted for which IO processor you are executing on. Enter either: 1 or 2. (Alternatively: "./configureTelORB.sh -c -i 1" for IO1 and "./configureTelORB.sh -c -i 2" for IO2.) (The configureTelORB.sh script will also stop and start the TelORB services.) 4. Only valid for EAB CW/OS lab (to make it possible to use tos1/tos2 later): Restore the /opt/telorb/etc/exports file to its original content, i.e. the following string should be added at the end of the "/opt/telorb" line in the exports file: 134.138.184.0/255.255.248.0(rw) (See step 1 above) To accomplish this, do as follows: cd /opt/telorb/etc/ cp uabexports exports (If uabexports exists and is valid) or vi exports (Update exports with the EAB CW/OS lab info string) Activate the exports settings by stopping and starting the TelORB services: /opt/telorb/etc/stop_services /opt/telorb/etc/start_services 5. Verify that all TelORB services, DHCP server and NFS server are running: /opt/telorb/etc/status_services 6. If you find it useful, verify that the telorb.conf changes have been correctly implemented in the dhcpd.pxe.conf file: more /opt/telorb/etc/dhcpd.pxe.conf The reconfiguration is now completed. Also reconfigure the other IO processor, if not already done. == == == == == == == == == == == == == == == == == == == == == == == == == == == Information about the scripts: To get more information about the two scripts used above, type: /opt/telorb/codearchive/iom_scripts/configureTelORB.sh -h /opt/telorb/codearchive/iom_scripts/prepareTelORB.sh -h Enter the following commands to start, stop or supervise the running TelORB services: /opt/telorb/etc/start_services /opt/telorb/etc/stop_services /opt/telorb/etc/status_services A log of which commands that have been run during the upgrade/installation/reconfiguration and their output can be found in /opt/telorb/installLog. The scripts change a couple of files like /opt/telorb/etc/dhcpd.pxe.conf, etc. A copy of the original file can be found below /opt/telorb/.installBackup. The format of these files looks as follows: Month.Day.Year_Hour:Minutes:Seconds_Absolute Path_Filename The slash (/) in the path is replaced by an underscore (_) example: May.11.2000_09:32:22_home_uabgros_rubbish_inetd.conf

General
 (Updated: 2002-11-06)

The procedure to upgrade the TelORB IO processor software (from now on called
"the IO tools package") is the same for JAP 3 (TelORB R14) and TSP 4 (TelORB
R14-Linux, Clusterware/OS), but some files and printouts differ, since JAP 3
uses Solaris as the operating system on the IO processors, whereas TSP 4 uses
Linux.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

README file for TSP 4.0 patch 5
 (Updated: 2002-11-06)

##################################################################
# This README descibes how to install TelORB-related services
# on an UNIX-IO-machine.
# All lines preceded by "prompt>" are commands that can be run in
# a shell.
##################################################################

This file is divided into three sections concerning 
a) upgrade of an older version of tools.tar,
b) installation of tools.tar on a new IO machine and
c) reconfiguration of all running services, e.g. when adding a
   processor to the system.

a) upgrading
############

After fetching tools.CXP901305.<revision>.tar you have to unpack the package under /opt/telorb.

prompt> cd /opt/telorb
prompt> tar xf tools.CXP901305.<revision>.tar

You end up having a directory "codearchive.CXP901305.<revision>".
Run upgradeTelORB.sh.

prompt> cd /opt/telorb/codearchive.CXP901305.<revision>/iom_scripts/
prompt> ./upgradeTelORB.sh

As a result either all services have been updated or you
need to follow the instructions in section b) installation. 
This might happen when important loadmodules have
been changed.


b) installation
###############

First of all stop all running services.

prompt> su root

If there is a file S15nfs* and S34Dhcp_isc under /etc/rc3.d/ run
prompt> /etc/rc3.d/S15nfs* stop
prompt> /etc/rc3.d/S34Dhcp_isc stop

Stop all TelORB-services
prompt> /etc/rc3.d/S88TelorbServices stop

Save the old codearchive under a different name
prompt> mv /opt/telorb/codearchive /opt/telorb/codearchive_`date '+%b.%d.%Y'`

Unpack tools.CXP901305.<revision>.tar under /opt/telorb if you haven't
done it yet.
You end up having created a directory "codearchive.CXP901305.<revision>".

Rename the new codearchive
prompt> mv /opt/telorb/codearchive.CXP901305.<revision> /opt/telorb/codearchive

The configuration-file, which should be /opt/telorb/etc/telorb.conf, must be prepared
according to the description in the example-file, called telorb.conf.example.
There is also a template-file, telorb.conf.templ.

If you run your system on GEM hardware you can use one of the
configuration files reflecting the GEM configuration,
i.e. r14_linux_maxi_zone1.telorb.conf.template etc. They are a good
starting point keeping the configuration as simple as possible.

The final version of telorb.conf must always be placed under /opt/telorb/etc !

Run "prepareTelORB.sh" logged in as "root". It will prepare the UNIX-system for 
usage as a TelORB-IO-machine.

prompt> cd /opt/telorb/codearchive/iom_scripts/
prompt> ./prepareTelORB.sh -p -c 
prompt> exit


c) reconfiguration
##################

When you have made changes to /opt/telorb/etc/telorb.conf
you have to update your configuration.
You need to be member of group telorb to run the following command.

prompt> ./configureTelORB.sh -c 

To read the help for both above mentioned scripts type
script -h, e.g. 
prompt> ./configureTelORB.sh -h


##################################################################

# starting, stopping and supervision

Run one of the following commands to start, stop or
supervise the running TelORB-services.

prompt> /opt/telorb/etc/start_services
prompt> /opt/telorb/etc/stop_services
prompt> /opt/telorb/etc/status_services

##################################################################

A log of which commands that have been run and their output can be
found in /opt/telorb/installLog.
The scripts change a couple of files like /opt/telorb/etc/dhcpd.pxe.conf etc.
A copy of the original file can be found under /opt/telorb/.installBackup.
The format of these files looks as follows:
Month.Day.Year_Hour:Minutes:Seconds_Absolute Path_Filename

The slash (/) in the path is replaced by a underscore (_)
example: May.11.2000_09:32:22_home_uabgros_rubbish_inetd.conf

General
 (Updated: 2004-12-13)

In TSP 5.0, the IO processors are included in the TSP cluster, which
is not the case for earlier TSP releases.

However, in TSP 5.1 the IO processors will be excluded from the cluster due to
instability problems.
The plan is to included them again in the near future.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Mixed info
 (Updated: 2004-01-26)

- To have the IO processors in the TSP cluster is not optional,
  all TSP 5.0 systems will have their IO processors in the cluster.

- The IO processors will be traffic processors as any other, except
  that they will boot from disk.
  I.e. the IO processors will be `regular' TSP processors.

- Linux TPs load whatever the PXE-server specifies, including Linux
  kernel and OS RAM disk, while the Dicos "smallPROM" loads an
  OS-loader via TFTP.
  Both OSes then continue to retrieve information about LMs what to
  load from the bootLoadTable.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Processes
 (Updated: 2004-01-26)

Some processes on the IO processors are started by xinetd.
These processes are listed in directory /etc/xinetd.d/ on the IO processors.
Directory /etc/xinetd.d/ is used in the file xinetd.conf.

  ps -ef | grep inet
  root      6892     1  0 Jan19 ?        00:00:22 xinetd -stayalive -reuse -pidfil

  cd xinetd.d
  ls -l
    total 92
    -rw-r--r--    1 root     root          428 Jan 19 15:59 alarmbridge
    -rw-r--r--    1 root     root          563 Jan 19 15:59 chargen
    -rw-r--r--    1 root     root          580 Jan 19 15:59 chargen-udp
    -rw-r--r--    1 root     root          419 Jan 19 15:59 daytime
    -rw-r--r--    1 root     root          438 Jan 19 15:59 daytime-udp
    -rw-r--r--    1 root     root          341 Jan 19 15:59 echo
    -rw-r--r--    1 root     root          360 Jan 19 15:59 echo-udp
    -rw-r--r--    1 root     root          313 Jan 19 15:59 eptftp
    -rw-r--r--    1 root     root          318 Jan 19 15:59 finger
    -rw-r--r--    1 root     root          259 Jan 19 15:59 ntalk
    -rw-r--r--    1 root     root          359 Jan 19 15:59 rexec
    -rw-r--r--    1 root     root          376 Jan 19 15:59 rlogin
    -rw-r--r--    1 root     root          429 Jan 19 15:59 rsh
    -rw-r--r--    1 root     root          365 Jan 19 15:59 rsync
    -rw-r--r--    1 root     root          312 Jan 19 15:59 servers
    -rw-r--r--    1 root     root          314 Jan 19 15:59 services
    -rw-r--r--    1 root     root          302 Jan 19 15:59 smartstatus
    -rw-r--r--    1 root     root          245 Jan 19 15:59 talk
    -rw-r--r--    1 root     root          303 Jan 19 15:59 telnet
    -rw-r--r--    1 root     root          200 Jan 19 15:59 tftp
    -rw-r--r--    1 root     root          497 Jan 19 15:59 time
    -rw-r--r--    1 root     root          518 Jan 19 15:59 time-udp
    -rw-r--r--    1 root     root          362 Jan 19 15:59 wu-ftpd

== == == == == == == == == == == == == == == == == == == == == == == == == ==

DRBD, Safe File System
 (Updated: 2004-02-12)

Nice links:
- DRBD HOWTO
- DRBD - Start
- DRBD - Publications: Data Redundancy By DRBD (e.g. How it works + Sync)

Detailed instructions can be found below the section for Shortcut instructions.

Note: To upgrade the IO processor software for JAP 3 and TSP 4 (TelORB R14 and TelORB R14-Linux), go
to IO processor software upgrade, installation and reconfiguration (tools).

Shortcut instructions Prerequisite: You must know the location from where to fetch the new tools.tar file. It is also a good idea to prepare the file /opt/telorb/etc/telorb.conf. If only a new telorb.conf file is to be "activated", perform steps 3, (4,) 9, 11 (only the first configureTelORB.sh), 13, 14, 15 & 16. Perform the following on both IO processors: 1. Check current tools version (introduced in TelORB release R14p7): more /opt/telorb/codearchive/version 2. If the TelORB Manager and the TelORB processor load viewer are running on the IO processor, close them. 3. Stop TelORB services, DHCP server and NFS server (the /opt/telorb/codearchive directory must exist to perform this step): /etc/rc3.d/S88TelorbServices stop (Stop TelORB services) psw (Type telorb password) /etc/rc3.d/S34Dhcp_isc stop (Stop DHCP server) (Not valid for TelORB R14 Linux) psw (Type telorb password) su (Enter superuser mode) psw (Type root password) /etc/rc3.d/S15nfs stop (Stop NFS server) (Not valid for TelORB R14 Linux) exit (Exit superuser mode) 4. If desired, save the existing codearchive directory below directory /opt/telorb/, for fallback reasons. 5. Fetch the tools.tar file to /opt/telorb/: id (if not telorb user, do `su telorb') cd /opt/telorb/ ftp 134.138.186.xx telorb psw Goto where the tools.tar file is going to be fetched from, e.g: cd /ipims_dicos/ipims_dicos10/dists/TelORB-R14/system/unix/ or cd /ipims_dicos/ipims_dicos10/dists/R14-patch/official/patch2/ TelORB-R14-Patch2-Runtime/unix/ or cd /uab/ipims_dicos/ipims_dicos10/dists/TSP4.0/EarlyDrop3.4/ TelORB-R14-Linux-Runtime3.4/system/unix bin get tools.tar bye 6. Unpack the fetched tools.tar file: tar xf tools.tar (For TelORB R14p10 and higher, see instructions below the "Shortcut instructions".) 7. If desired, remove the fetched tools.tar file: rm tools.tar 8. Check if the new IO tools package requires any changes to the telorb.conf file. If so, edit the telorb.conf file accordingly (/opt/telorb/etc/telorb.conf). 9. EAB CW/OS lab specific (to make it possible to use tos1/tos2 later) (valid from TelORB R14p2): Save the following information for reference reasons: more /opt/telorb/etc/dfstab (For Solaris OS) or more /opt/telorb/etc/exports (For Linux OS) 10. If desired, save the existing plLoadable file below directory /tftpboot/telorb/ppro/, for fallback reasons. 11. The preparation and configuration routine was changed in TelORB R14 predrop 3.1 for TSP 4.0. Therefore, this section is divided into two parts. Instructions for R13 upto, but not including, R14 predrop 3.1 ------------------------------------------------------------- Install the IO tools package on the IO processor: su root (Enter root mode) psw (Type password) cd /opt/telorb/codearchive/iom_scripts/ ./prepareTelORB.sh -vp (Prepares a UNIX system for usage as a TelORB IO processor) su telorb (Enter telorb mode) ./configureTelORB.sh -c /opt/telorb/etc/telorb.conf (Creates a lot of TelORB related files) ./configureTelORB.sh -vu (Updates /tftpboot/telorb/ppro/plLoadable, and also other files for TSP 4.0) Instructions for R14 predrop 3.1 and higher ------------------------------------------- Install the IO tools package on the IO processor: su root (Enter root mode) psw (Type password) cd /opt/telorb/codearchive/iom_scripts/ ./prepareTelORB.sh -p -c /opt/telorb/etc/telorb.conf exit (Exit root mode) If only changes to the telorb.conf file have been made, it is only necessary to perform the following: cd /opt/telorb/codearchive/iom_scripts/ more /opt/telorb/etc/exports ./configureTelORB.sh -c /opt/telorb/etc/telorb.conf cd /opt/telorb/etc cp uabexports exports (If uabexports exists) (Update exports with EAB CW/OS lab info) or vi exports (Update exports with EAB CW/OS lab info) ./stop_services ./start_services ./status_services more dhcpd.pxe.conf (Verify changes, if necessary) 12. Check new tools version: more /opt/telorb/codearchive/version 13. EAB CW/OS lab specific (to make it possible to use tos1/tos2 later) (valid from TelORB R14p2): Restore the /opt/telorb/etc/dfstab file (Solaris) or /opt/telorb/etc/exports file (Linux) to its original content, e.g. the following string should be added at the end of the "/opt/telorb" line in the exports file: 134.138.184.0/255.255.248.0(rw) 14. Start NFS server, DHCP server and TelORB services by either rebooting the IO processor or by manually starting the NFS server, DUCK server and TelORB services: Reboot: su (Enter superuser mode) psw (Type password) reboot (For Solaris OS) or /sbin/reboot (For Linux OS) Manually: su (Enter superuser mode) psw (Type root password) /etc/rc3.d/S15nfs start (Start NFS server) exit (Exit superuser mode) /etc/rc3.d/S34Dhcp_isc start (Start DHCP server) psw (Type telorb password) /etc/rc3.d/S88TelorbServices start (Start TelORB services) psw (Type telorb password) 15. Verify that NFS server, DHCP server and TelORB services are running: ps -ef | grep nfs (For Solaris OS or Linux OS) or /usr/sbin/exportfs (For Linux OS) /opt/telorb/etc/status_dhcp (Not valid for TelORB R13, use ps -ef) /opt/telorb/etc/status_services 16. EAB CW/OS lab specific (to make it possible to use tos1/tos2 later): Check the mountings on the tos1/tos2 machines to verify that these are correct. Do the following on tos1/tos2: ls -l /toX/toXioY/telorb/axe/ (Adjust toX to valid TelORB system, adjust ioY to valid IO processor (or use IP address)) If the mountings are not correct, i.e. you cannot check the files at /toX/toXioY/telorb/axe/, it may be sufficient to just umount and mount (e.g. /toX/toXioY/telorb for TSP 4.0 and later). See section Add TelORB system to EAB CW/OS lab environment (tos1/tos2 mounting) for details. 17. Upgrade the software for 3rd Party Products (3PP) as specified in Upgrade the software for 3rd Party Products (3PP) below. 18. Add EAB CW/OS lab specific "Loadable Extras" to the TelORB Manager as specified in Add EAB CW/OS lab specific "Loadable Extras below. 19. Start TelORB processor log files and consoles as specified in Start TelORB processor log files and consoles. 20. Start (and connect) the TelORB Manager as specified in Start TelORB Manager/Browser and alarm & notification window. 21. Start the TelORB processor load viewer as specified in Start TelORB processor load viewer.

General
The procedure to upgrade the TelORB IO processor software is slightly different
in TelORB R13 and higher than it was for earlier releases. See below for details.

To check the release note of a TelORB release or patch, modify the URL below to
the TelORB release of your choice and use the URL in a web browser. A pdf-file,
containing the release note, will be opened.
By clicking on the link below, the TelORB release note for TelORB R14 patch 2
will be opened.
file:/uab/ipims_dicos/ipims_dicos10/dists/R14-patch/official/patch2/R14-Patch2-ReleaseNote.pdf

-  -  -  -  -  -  -  -  -

For TelORB R14p10 and higher, the following apply:
As a result of my trouble report UABtr0416, the IO tools package handling has
been changed from TelORB R14p10 and onwards.
The IO tools packages has got a different name, e.g.
"tools.CRA119669.<version>.tar" reflecting the package number and its
current revision.
After fetching and unpacking a new IO tools package, the unpacked codearchive
directory is called e.g. "codearchive.CRA119669.<version>" following the same
name pattern as that for the tar file.
Apart from this, there is a file below the codearchive directory holding this
information as well.

Upgrading tools can be done using a script called upgradeTelORB.sh.
If no major changes have been made, the TelORB services will be stopped, the new
loadmodules will be copied, and "everything" is started.
If there are major changes, the script will refer to an installation procedure.

When installing tools, the user can first make changes to the telorb.conf file.
After that, TelORB services have to be stopped before running prepareTelORB.sh
as follows:
  prepareTelORB.sh -p -i 1 -c /opt/telorb/etc/telorb.conf

You don't need to run configureTelORB.sh during installation.

If you just have made changes to the telorb.conf file, e.g. you have replaced a
processor board which leads to that MAC addresses have to be modified, you can
run configureTelORB.sh as follows:
  configureTelORB.sh -c /opt/telorb/etc/telorb.conf
This will stop the TelORB services, regenerate all configuration files and start
the TelORB services.

-  -  -  -  -  -  -  -  -

Note: The upgrading instructions below should be performed on both IO processors,
one after the other.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check current tools version
This possibility was introduced in TelORB release R14p7.

  more /opt/telorb/codearchive/version

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Stop TelORB services, DHCP server and NFS server
If the TelORB Manager and the TelORB processor load viewer (./Win.LM_MD45...)
are running on the IO processor, close them and then proceed below.

Stop TelORB services, DHCP server and NFS server that are currently running on
the IO processor:
  /etc/rc3.d/S88TelorbServices stop  (Requires telorb password)
  /etc/rc3.d/S34Dhcp_isc stop        (Requires telorb password)
  su                                 (Enter superuser mode)
  psw                                (Type password)
  /etc/rc3.d/S15nfs stop
  exit                               (Exit superuser mode)
  ps -ef                             (Verify that no processes for TelORB
                                      services, DHCP server and NFS server
                                      are executing. If such processes are
                                      executing, kill them by using "kill
                                      <PID>").

  In TSP 4.0 (R14-Linux) or later releases, the NFS server is stopped by
  entering:
    /etc/init.d/nfs stop

  (The NFS server is included in the Linux kernel.)

Bonus info: Alternative way of stopping TelORB services and DHCP server
-----------------------------------------------------------------------
If you are currently running TelORB R14, it is also possible to use the
following command sequence to stop TelORB services and DHCP server:
  cd /opt/telorb/etc/
  ./status_services           (Check status of TelORB processes)
  ./stop_services             (Stop TelORB services processes on IO processor)
                              (Note that RPC, NFS and NTP are also stopped)
  ./status_services           (Check status of TelORB processes)
  ./status_dhcp               (Check status of DHCP processes)
  ./stop_dhcp                 (Stop DHCP processes on IO processor)
  ./status_dhcp               (Check status of DHCP processes)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Fetch and unpack the IO tools package
Precaution: If you want to save the existing codearchive directory below
            /opt/telorb/ on the IO processor (for fallback reasons), rename it
            before proceeding, since it will be overwritten when unpacking the
            IO tools package (e.g. mv codearchive codearchive.old (preferably
            use a name containing the release name)).

On the IO processor, fetch the file "tools.tar" from the distribution or from a
patch package to directory /opt/telorb/ by using ftp:
  su telorb                        (Enter telorb mode, if not already done (id))
  cd /opt/telorb/
  ftp 134.138.186.xx               (Adjust to valid IP address from where
                                    the IO tools package is accessible)
  telorb                           (Log in as telorb user)
  psw                              (Type telorb password)

  Either fetch from the base TelORB release location, e.g. R14:
    cd /ipims_dicos/ipims_dicos10/dists/TelORB-R14/system/unix/
  or from a patch, e.g. R14p2:
    cd /ipims_dicos/ipims_dicos10/dists/R14-patch/official/patch2/TelORB-R14-Patch2-Runtime/unix/
                                   (Adjust TelORB-R14 or patch level to valid
                                    release or patch)
  bin                              (Enter binary transfer mode)
  get tools.tar                    (Fetch file)
  bye                              (Exit ftp)

Unpack the fetched tar file:
  tar xf tools.tar                 (The existing codearchive directory below
                                    /opt/telorb/ will be overwritten)

Remove the fetched tar file, if desired:
  rm tools.tar

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check if the new IO tools package requires any changes to the file telorb.conf
Compare the telorb.conf file below /opt/telorb/etc/ on the IO processor with
the template and/or example files in the fetched IO tools package:
  more /opt/telorb/etc/telorb.conf
  more /opt/telorb/codearchive/iom_scripts/telorb.conf.templ
  more /opt/telorb/codearchive/iom_scripts/telorb.conf.example

If necessary, modify the telorb.conf file according to the example and/or
template files so that it suits your system. (The telorb.conf file is identical
on IO1 and IO2, so when the telorb.conf file has been modified on one of the IO
processors it can be copied to the other IO processor.):
  Copy the existing telorb.conf file with another name for fallback reasons
    (cp telorb.conf telorb_conf.old (preferably use a name containing the
     release name))
  cd /opt/telorb/etc/
  Edit telorb.conf

EAB CW/OS lab specific  (Valid from TelORB R14p2 and onwards. Not valid for
----------------------  TelORB R13.)
Do the following because the EAB CW/OS lab is using tos1/tos2.
The file /opt/telorb/etc/dfstab (valid for Solaris OS) or
/opt/telorb/etc/exports (valid for Linux OS) will be modified when running
the first configureTelORB script below. Therefore, save the contents of this
file (dfstab or exports) to be able to insert it in the same file after it has
been modified (as described further down in this procedure).
  more /opt/telorb/etc/dfstab                             (Valid for Solaris OS)
    or
  more /opt/telorb/etc/exports                              (Valid for Linux OS)
     (The printout may look something like:
	/usr/sbin/exportfs
	/opt/telorb   	134.138.61.0/255.255.255.0          (61=to25 net A)
	/opt/telorb   	134.138.62.0/255.255.255.0          (62=to25 net B)
	/opt/telorb   	134.138.184.0/255.255.248.0)        (EAB CW/OS lab
                                                             special)

Hints:
More information about the telorb.conf file and how it will be used further down
in these instructions can be found in the file /opt/telorb/codearchive/README.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Install the new IO tools package
Precaution: If you want to save the existing plLoadable file below directory
            /tftpboot/telorb/ppro/ on the IO processor (for fallback reasons),
            rename it before proceeding below, since it will be overwritten when
            executing the second configureTelORB.sh script
            (e.g. mv plLoadable plLoadable.old (preferably use a name containing
             the release name)).

Install the IO tools package on the IO processor:
  su root                              (Enter root mode)
  psw                                  (Type password)
  cd /opt/telorb/codearchive/iom_scripts/
  ./prepareTelORB.sh -vp               (Prepares a UNIX system for usage as a
                                        TelORB IO processor. Changes lots of
                                        permission settings, file ownerships and
                                        creates /etc/rc3.d/S34Dhcp_isc,
                                        creates /etc/rc3.d/S88TelorbServices,
                                        removes /etc/rc3.d/S15TelorbServices.
                                        The prepareTelORB script takes a while,
                                        so be patient.
                                        To get debug printouts while running the
                                        script, remove the hash sign (#) in the
                                        script at: "#set -x")
  Wait for the prompt. (For TelORB R14p2, the script ends with the line
                       "/bin/ln -s /opt/telorb/etc/dfstab /etc/dfs/dfstab".
                        For TelORB R14pX, the script ends with the line
                        "/bin/ln -s /etc/rc.d/init.d/TelorbServices
                        /etc/rc.d/rc0.d/K88TelorbServices".)

  su telorb                            (Enter telorb mode)
  ./configureTelORB.sh -c /opt/telorb/etc/telorb.conf
                                       (The TelORB configuration file
                                        /opt/telorb/etc/telorb.conf must be
                                        prepared before running this script.
                                        Creates a lot of TelORB related files,
                                        see below.
                                        To get debug printouts while running the
                                        script, remove the hash sign (#) in the
                                        script at: "#set -x")

  Wait for the prompt.

      Example of printout for TelORB R14p2:
	On which IO-machine are you running [1/2] 1

        creating /opt/telorb/etc/start_services ...
        /opt/telorb/etc/start_services created

        creating /opt/telorb/etc/stop_services ...
        /opt/telorb/etc/stop_services created

        creating /opt/telorb/etc/status_services ...
        /opt/telorb/etc/status_services created

        creating /opt/telorb/etc/dhcpd.pxe.conf ...
        /opt/telorb/etc/dhcpd.pxe.conf created

        creating /opt/telorb/etc/start_dhcp ...
        /opt/telorb/etc/start_dhcp created

        creating /opt/telorb/etc/stop_dhcp ...
        /opt/telorb/etc/stop_dhcp created

        creating /opt/telorb/etc/status_dhcp ...
        /opt/telorb/etc/status_dhcp created

        creating /opt/telorb/etc/ep_tftpd.conf ...
        /opt/telorb/etc/ep_tftpd.conf created

        creating /opt/telorb/etc/transfermgr.conf ...
        /opt/telorb/etc/transfermgr.conf created

        creating /opt/telorb/etc/rsyncd.conf ...
        /opt/telorb/etc/rsyncd.conf created

        creating /opt/telorb/etc/dfstab ...               (exports for Linux OS)
        /opt/telorb/etc/dfstab created                    (exports for Linux OS)

        creating /opt/telorb/etc/crashcollector.conf ...
        /opt/telorb/etc/crashcollector.conf created

	creating /opt/telorb/etc/pxe.cf ...        (currently only for Linux OS)
	/opt/telorb/etc/pxe.cf created             (currently only for Linux OS
      End of example printout.

      Example of printout for TelORB R13:
	On which IO-machine are you running [1/2] 1

	creating /opt/telorb/etc/start_services ...
	/opt/telorb/etc/start_services created

	creating /opt/telorb/etc/stop_services ...
	/opt/telorb/etc/stop_services created

	creating /opt/telorb/etc/dhcpd.pxe.conf ...
	/opt/telorb/etc/dhcpd.pxe.conf created

	creating /opt/telorb/etc/start_dhcp ...
	/opt/telorb/etc/start_dhcp created

	creating /opt/telorb/etc/ep_tftpd.conf ...
	/opt/telorb/etc/ep_tftpd.conf created
      End of example printout.


  ./configureTelORB.sh -vu            (Updates /tftpboot/telorb/ppro/plLoadable,
                                       and also other files for TSP 4.0)

      Example of printout for TelORB R14pX (TSP 4.0 Clusterware & OS):
	/bin/cp /tftpboot/telorb/ppro/plLoadable /opt/telorb/.installBackup/Oct.25.2001_17:22:30_tftpboot_telorb_ppro_plLoadable
	/bin/chmod 444 /opt/telorb/.installBackup/Oct.25.2001_17:22:30_tftpboot_telorb_ppro_plLoadable
	/bin/rm /tftpboot/telorb/ppro/plLoadable
	/bin/cp /opt/telorb/codearchive/OS_LoaderIA32_LM/bin//plLoadable /tftpboot/telorb/ppro/.
	/bin/chmod 755 /tftpboot/telorb/ppro/plLoadable
	/bin/cp /opt/telorb/codearchive/OS_LoaderIA32_LM/bin//plPXE.0 /tftpboot/X86PC/UNDI/Dicos/.
	/bin/cp /opt/telorb/codearchive/OS_LoaderIA32_LM/bin//plPXE.1 /tftpboot/X86PC/UNDI/Dicos/.
	/bin/chown telorb:telorb /tftpboot/X86PC/UNDI/Dicos/plPXE.0
	/bin/chown telorb:telorb /tftpboot/X86PC/UNDI/Dicos/plPXE.1
	/bin/chmod 755 /tftpboot/X86PC/UNDI/Dicos/plPXE.0
	/bin/chmod 755 /tftpboot/X86PC/UNDI/Dicos/plPXE.1
	/bin/cp /opt/telorb/codearchive/OS_LoaderIA32_LM/bin//linux.0 /tftpboot/X86PC/UNDI/linux-tp/.
	/bin/chown telorb:telorb /tftpboot/X86PC/UNDI/linux-tp/linux.0
	/bin/chmod 755 /tftpboot/X86PC/UNDI/linux-tp/linux.0
      End of example printout.

      Example of printout for TelORB R14p2:
	/bin/cp /tftpboot/telorb/ppro/plLoadable /opt/telorb/.installBackup/Aug.29.2001_16:12:43_tftpboot_telorb_ppro_plLoadable
	/bin/chmod 444 /opt/telorb/.installBackup/Aug.29.2001_16:12:43_tftpboot_telorb_ppro_plLoadable
	/bin/rm /tftpboot/telorb/ppro/plLoadable
	/bin/cp /opt/telorb/codearchive/OS_LoaderIA32_LM/bin//plLoadable /tftpboot/telorb/ppro/.
	/bin/chmod 755 /tftpboot/telorb/ppro/plLoadable
      End of example printout.

      Example of printout for TelORB R13:
	/bin/cp /tftpboot/telorb/ppro/plLoadable /opt/telorb/.installBackup/May.10.2001_15:34:54_tftpboot_telorb_ppro_plLoadable
	/bin/chmod 444 /opt/telorb/.installBackup/May.10.2001_15:34:54_tftpboot_telorb_ppro_plLoadable
	/bin/rm /tftpboot/telorb/ppro/plLoadable
	/bin/cp /opt/telorb/codearchive/IntelPcProm_LM/bin/plLoadable /tftpboot/telorb/ppro/.
	/bin/chmod 755 /tftpboot/telorb/ppro/plLoadable
      End of example printout.

Verify that the following files have been updated correctly:
  more /opt/telorb/etc/dhcpd.pxe.conf
  more /opt/telorb/etc/start_services
  more /opt/telorb/etc/ep_tftpd.conf
  more /opt/telorb/etc/dfstab      (Only for Solaris OS. See EAB special below!)
  more /opt/telorb/etc/exports       (Only for Linux OS. See EAB special below!)

  ls -l /tftpboot/telorb/ppro/plLoadable   (Check size)


Check new tools version
-----------------------
This possibility was introduced in TelORB release R14p7.

  more /opt/telorb/codearchive/version


EAB special (Valid from TelORB R14p2 and onwards. Not valid for TelORB R13.)
-----------
The file /opt/telorb/etc/dfstab (valid for Solaris OS) or
/opt/telorb/etc/exports (valid for Linux OS) was modified above when the
first configureTelORB script was run. 
At the EAB CW/OS lab (because we are using tos1/tos2), the file /opt/telorb/etc/dfstab or
/opt/telorb/etc/exports should look as described below the dfstab or exports
heading below. Adjust xx and yy to valid A and B network addresses (e.g. 63 and
64 for TelORB system to20).
(The dfstab and exports files, respectively, are identical on IO1 and IO2, so
when the dfstab or exports file has been modified on one of the IO processors it
can be copied to the other IO processor.)

  cd /opt/telorb/etc/

  dfstab (Valid for Solaris OS) 
  ------
  Edit the dfstab file so that it looks as follows. Preferably use the result of
  the more command, which was entered at the previous "EAB special" point above
  (copy and paste):

    share -F nfs -o rw=@134.138.xx:@134.138.yy:@134.138.187 /opt/telorb
    share -F nfs -o rw=@134.138.xx:@134.138.yy:@134.138.187 /opt/telorb/axe
    share -F nfs -o rw=@134.138.xx:@134.138.yy:@134.138.187 /opt/telorb/dumps
    share -F nfs -o rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se /tftpboot
    share -F nfs -o rw=tos1.uab.ericsson.se:tos2.uab.ericsson.se,root=tos1.uab.ericsson.se:tos2.uab.ericsson.se /etc

Actually, the first line for /opt/telorb/ and the last two lines for tos1/tos2
can probably be excluded, but we'll keep them for a while just in case
"something" needs them.

  exports (Valid for Linux OS)
  -------
  Edit the exports file so that it looks as follows. Preferably use the result
  of the more command, which was entered at the previous "EAB special" point
  above (copy and paste):
    For TSP 4.0 and later:
      /opt/telorb 134.138.xx.0/255.255.255.0(rw,sync) 134.138.yy.0/255.255.255.0(rw,sync) 134.138.184.0/255.255.248.0(rw)
                           (Adjust xx and yy to valid A and B network addresses)

    For TelORB R14:
      /opt/telorb 134.138.xx.0/255.255.255.0(rw) 134.138.yy.0/255.255.255.0(rw) 134.138.184.0/255.255.248.0(rw)
                           (Adjust xx and yy to valid A and B network addresses)

  If the exports file is copied from the other IO processor, make sure it has
  the following permissions: "-rwxr-xr-x    1 telorb   telorb".
    (To activate the dfstab file (into sharetab) if it has been modified, as
     well as activating the rest of the configured TelORB stuff, the IO
     processor should be rebooted as described below.)
    (To activate the exports file settings (visible in command
     /usr/sbin/exportfs) if they have been modified, as well as activating the
     rest of the configured TelORB stuff, the IO processor should be rebooted as
     described below.)
    (To activate only the export file settings, enter command
     `/usr/sbin/exportfs -ra' (This has not yet been verified, info from
      uablrek.))
    (To restart only the NFS server and activate the export file settings:
      su
      /etc/rc3.d/S15nfs restart)
    (To verify that the exports file settings have been activated:
      /usr/sbin/exportfs)

If the directory /opt/telorb/axe/upgradePackages/ is not created on IO1, create
it:
  mkdir /opt/telorb/axe/upgradePackages/

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start NFS server, DHCP server and TelORB services
Reboot the IO processor. This is the preferred and official alternative.
  su                                     (Enter superuser mode)
  reboot

After the reboot, verify that NFS is running:
  ps -ef | grep nfs                      (Get status on Solaris OS or Linux
                                          OS)
    or
  /usr/sbin/exportfs                     (Get status on Linux OS)

Verify that DHCP is running (not valid for TelORB R13, use ps -ef instead):
  /opt/telorb/etc/status_dhcp

Verify that the rest of the TelORB services are running (not valid for TelORB
R13, use ps -ef instead):
  /opt/telorb/etc/status_services


Bonus info: Alternative way of starting NFS, DHCP and TelORB services
---------------------------------------------------------------------
If you do not want to reboot the IO processor, do the following on the IO
processor:

  su telorb                        (Enter telorb mode, if not already done (id))

  Start NFS server:
    ps -ef | grep nfs                    (Get status before on Solaris OS or
                                          Linux OS)
      or
    /usr/sbin/exportfs                   (Get status before on Linux OS)

    su                                   (Enter superuser mode)
    psw                                  (Type password)

    /etc/rc3.d/S15nfs start (or restart) (Start NFS server)

    ps -ef | grep nfs                    (Get status after on Solaris OS or
                                          Linux OS)
      or
    /usr/sbin/exportfs                   (Get status after on Linux OS)

    exit                                 (Exit superuser mode)

  Start DHCP server:
    /etc/rc3.d/S34Dhcp_isc start         (Start DHCP server)
                                         (Requires telorb password)
                                         (The script is ready when the printout
                                          stops. Just hit the Enter key to get a
                                          prompt.

  Start TelORB services:
    /etc/rc3.d/S88TelorbServices start   (Start TelORB services)
                                         (Requires telorb password)
                                         (The script is ready when the printout
                                          stops. Just hit the Enter key to get a
                                          prompt.


Bonus info: Yet an alternative way of starting TelORB services and DHCP
-----------------------------------------------------------------------
If you are currently running TelORB R14, it is also possible to use the
following command sequence to start TelORB services and DHCP:
  su telorb                   (Enter telorb mode, if not already done (id))
  cd /opt/telorb/etc/
  ./status_services           (Verify that TelORB processes are stopped)
  ./start_services            (Start TelORB processes)
                              (Ends with "..Installing ChainBindInterceptor!..",
                                     no prompt returned)
  ./status_services           (Check status of TelORB processes)
    Example of printout for TelORB R14p2:
	guardFsi (pid 426) is running ...
	guardDs (pid 368) is running ...
	guardEptftp (pid 403) is running ...
	guardDump (pid 493) is running ...
	guardSts (pid 530) is running ...
	guardSysC (pid 574) is running ...
	guardAppC (pid 627) is running ...
	guardTrMgr (pid 693) is running ...
	guardCrashCo (pid 471) is running ...
	FileServerInterpreter.LM_AXG428.R1I03.sparc-SunOS-5.6 (pid 472) is running ...
	DUCKServer.LM_MD12.R1I03.sparc-SunOS-5.6 (pid 412) is running ...
	TftpDumpd.LM_MD44.R1I02.sparc-SunOS-5.6 (pid 607) is running ...
	EpTftpd.LM_MD41.R1I03.sparc-SunOS-5.6 (pid 464 465) is running ...
	STSsw.LM_D14.R1I02.sparc-SunOS-5.6 (pid 683) is running ...
	DicosSyslogClient.LM_D35.R1I02.sparc-SunOS-5.6 (pid 694) is running ...
	DicosApplogClient (pid 705) is running ...
	TransferManager.LM_D109.R1A11.jar (pid 720) is running ...
	CrashCollector.LM_D121.R1B01.sh (pid 506) is running ...
    End of printout example.

    Observe that the result from running the status_services script shows that
    DicosApplogClient.LM_D81.R1A05.sparc-SunOS-5.6 is stopped. This is not true.
    Use `ps -ef | grep pp' to check that the DicosApplogClient and its guard
    are running.

  ./status_dhcp               (Verify that the DHCP processes are stopped)
  ./start_dhcp                (Start TelORB processes)
                              (Ends with "...Socket/fallback/fallback-net",
                               no prompt returned)
  ./status_dhcp               (Check status of DHCP processes)
    Example of printout:
	guardDhcp (pid 332) is running ...
	Dhcp.LM_D54.R1J05.sparc-SunOS-5.6 (pid 567) is running ...
    End of printout example.


EAB special
-----------
Check the mountings on the tos1/tos2 machines to verify that these are correct.
See section Add TelORB system to the EAB CW/OS lab environment (tos1/tos2 mounting) for
details.
One way of checking the tos1/tos2 mountings is to enter the following in
tos1/tos2:
  ls -l /toX/toXioY/telorb/axe/            (Adjust toX to valid TelORB system,
                                            adjust ioY to valid IO processor
                                            (or use IP address))

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Upgrade the software for 3rd Party Products (3PP)
 (Updated: 2001-08-24)

This part is valid for TelORB R14 and may already be done for your system.

Fetch the file "rsyncJavaVb010824.tar" (which contains Java, rsync and
Visibroker) from "/opt/" on IO processor to20io1 to your IO processor, directory
"/opt/", by using ftp:
  Log in to the target IO processor, i.e. the IO processor to be upgraded with
  3PP.
  su root                              (Enter superuser mode)
  cd /opt/
  Remove all symbolic links to java, rsync and visibroker, if any:
    rm java rsync vbroker
  Rename or delete the current 3rdParty directory.
    ftp 134.138.187.89     (IP address to to20io1. Adjust IP address if the file
                            is to be fetched from another location)
  telorb
  psw
  cd /opt/
  bin
  get rsyncJavaVb010824.tar        (Latest version as of 2001-08-24. Adjust file
                                    name if another version is to be fetched)
  bye

Unpack the fetched file:
  tar xf rsyncJavaVb010824.tar

Insert the following line in ~/.cshrc after the "set path..." command:
  source /opt/3rdParty/env.csh

Insert the following line in ~/.profile after the line "export PATH" (observe
that there should be a space character between the "." and the "/"; ". " means
"source" in one of the shell types):
  . /opt/3rdParty/env.sh

Insert the following line at the end of the file /etc/inetd.conf:
  rsync stream tcp nowait root /opt/rsync rsync --daemon --config=/opt/telorb/etc/rsyncd.conf

Insert the following line at the end of the file /etc/services:
  rsync           873/tcp

Reboot the IO processor (su, reboot), or do "source .cshrc" (or ". ./.profile")
and "kill -HUP 'ps id for inetd'". (The kill command does not kill the HUP
process.)

Remove the tar file and exit root mode:
  rm rsyncJavaVb010824.tar
  exit

Instructions for upgrading Java, Visibroker och Rsync can also be found in:
  /home/dicostest/systest/users/uabmat/install3pp.txt

     (The following is included in the rsyncJavaVb010824.tar file and is not
     necessary to perform again:
       Create 3 links below directory "/opt/" on the IO processor:
         ln -s /opt/3rdParty/vbroker/ vbroker
         ln -s /opt/3rdParty/Solaris_JDK_1.2.2_07/ java
         ln -s /opt/3rdParty/rsync/bin/rsync* rsync
       Copy the contents of the /home/telorb/visijars/lib directory to visijars:
         ls -l /home/telorb/visijars/
         cp /home/telorb/visijars/lib/* /home/telorb/visijars/)

 == == == == == == == == == == == == == == == == == == == == == == == == == ==

Add EAB CW/OS lab specific "Loadable Extras" to the TelORB Manager
This part is valid for TelORB R14.

Fetch the file TelORBManagerExtras.jar to the IO processor:
  su telorb                      (Enter telorb mode, if not already done (id))
  cd /opt/telorb/codearchive/Unix_IDP/included/LM_D115-TelORBManager/jar/
  ftp 134.138.186.xx             (Adjust to valid IP address)
  telorb
  psw
  bin
  cd /ipims_dicos/ipims_dicos10/dists/TelORB-R14/examples/IDP_D28-TelORBManagerExtras/included/LM_D116-TelORBManager/jar/
                                            (Adjust TelORB-R14 to valid release)
    (or from a testbed: cd /ipims_dicos/ipims_dicos20/BS2/tbTEST1.3/TEST_IDPG/TelORBManagerExtras_IDP/TelORBManagerExtras_LM/jar/)
                                 (Adjust tbTEST1.3 to valid release)
  get TelORBManagerExtras.jar
  bye

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Start TelORB processor log files, consoles, TelORB Manager and TelORB processor
load viewer on one of the IO processors
Start TelORB processor log files and consoles as specified in
Start TelORB processor log files and consoles.

Start (and connect) the TelORB Manager as specified in
Start TelORB Manager/Browser and alarm & notification window.

Start the TelORB processor load viewer as specified in
Start TelORB processor load viewer.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
DHCP problem
------------
If DHCP does not start in TelORB R13, R14 and probably higher here are some
hints on how to get it started.
- Check DHCP configuration data in the telorb.conf file.
- Remove the /etc/dhcpd.pid file and any other pid files below /etc/ and rerun
  the tools installation scripts (prepareTelORB.sh and configureTelORB.sh). See
  above for instructions.

To check what is changed in the codearchive, the following will give you a list
of the changes between the old codearchive and the new, e.g. on the IO
processor:
  cd /opt/telorb/
  dircmp -s codearchive codearchive.r13.10

You could also use a '-d' option to tell you what has changed in each file.

tftpd problem  (Valid for Linux OS)
-------------
If the loading of a TelORB processor stops and the printout from the serial
terminal shows something like "Key: bp_eth0_serveraddress
                               No bootmodule filename found in Prom DB"
try the following to check if the file permissions are correct:
> tftp 134.138.79.225
> mode octet
> get X86PC/UNDI/Dicos/plPXE.0
Received 8977 bytes in 0.0 seconds    (Permissions OK)
> quit

> tftp to25io1
> mode octet
> get X86PC/UNDI/Dicos/plPXE.0
Error code 2: Access violation        (Permissions NOK, change file permissions)
> quit

== == == == == == == == == == == == == == == == == == == == == == == == == ==

README file for TSP 4.0 EarlyDrop 3.4
more /opt/telorb/codearchive/version 
  CXP901305.R1H01
cd /opt/telorb/codearchive/
more README 
##################################################################
# This README descibes how to install TelORB-related services
# on an UNIX-IO-machine.
# All lines preceded by "prompt>" are commands that can be run in
# a shell.
##################################################################

This file is devided into three section concerning 
a) upgrade of an older version of tools.tar,
b) installation of tools.tar on a new IO machine and
c) reconfiguration of all running services.

a) upgrading
############

After fetching tools.CRA119669.<revision>.tar you have to unpack the package under /opt/telorb.

prompt> cd /opt/telorb
prompt> tar xf tools.CRA119669.<revision>.tar

You end up having a directory "codearchive.CRA119669.<revision>".
Run upgradeTelORB.sh.

prompt> cd /opt/telorb/codearchive.CRA119669.<revision>/iom_scripts/
prompt> ./upgradeTelORB.sh

As a result either all services have been updated or you
need to follow the instructions in section b) installation. 
This might happen when important loadmodules have
been changed.


b) installation
###############

First of all stop all running services.

If there is a file S15nfs* and S34Dhcp_isc under /etc/rc3.d/ run
prompt> su root
prompt> /etc/rc3.d/S15nfs* stop
prompt> /etc/rc3.d/S34Dhcp_isc stop

Stop all TelORB-services
prompt> /etc/rc3.d/S88TelorbServices stop

Save the old codearchive under a different name
prompt> mv /opt/telorb/codearchive /opt/telorb/codearchive_`date '+%b.%d.%Y'`

Unpack tools.CRA119669.<revision>.tar under /opt/telorb if you haven't
done it yet.
You end up having created a directory "codearchive.CRA119669.<revision>".

Rename the new codearchive
prompt> mv /opt/telorb/codearchive.CRA119669.<revision> /opt/telorb/codearchive

The configuration-file, which should be /opt/telorb/etc/telorb.conf, must be prepared
according to the description in the example-file, called telorb.conf.example.
There is also a template-file, telorb.conf.templ.

If you run your system on GEM hardware you can use one of the
configuration files reflecting the GEM configuration,
i.e. r14_linux_maxi_zone1.telorb.conf.template etc. They are a good
starting point keeping the configuration as simple as possible.

The final version of telorb.conf must always be placed under /opt/telorb/etc !

Run "prepareTelORB.sh" logged in as "root". It will prepare the UNIX-system for 
usage as a TelORB-IO-machine.

prompt> cd /opt/telorb/codearchive/iom_scripts/
prompt> ./prepareTelORB.sh -p -c 
prompt> exit


c) reconfiguration
##################

When you have made changes to /opt/telorb/etc/telorb.conf
you have to update your configuration.
You need to be member of group telorb to run the following command.

prompt> ./configureTelORB.sh -c 

To read the help for both above mentioned scripts type
script -h, e.g. 
prompt> ./configureTelORB -h


##################################################################

# starting, stopping and supervision

Run one of the following commands to start, stop or
supervise the running TelORB-services.

prompt> /opt/telorb/etc/start_services
prompt> /opt/telorb/etc/stop_services
prompt> /opt/telorb/etc/status_services

General
Select what to upgrade:
1. Upgrade an LM
2. Upgrade the complete IDP_MD15_Unix directory
3. Upgrade the complete IO tools package (directory)

Templates for the file start_services:
more /opt/telorb/tools/etc/io1.start_services
more /opt/telorb/tools/etc/io2.start_services

Templates for the file ep_tftpd.conf:
more /opt/telorb/tools/etc/io1.ep_tftpd.conf
more /opt/telorb/tools/etc/io2.ep_tftpd.conf

Note that the line "...DicosSyslogClient..." in the file "start_services" has a
different look depending on which AD that is used:
AD11.4.1 (to8/IO1):  /opt/telorb/tools/bin/DicosSyslogClient -L -m io1 -t 134.138.81.101-128 > /opt/telorb/syslog &
AD11.4.1 (to8/IO2):  /opt/telorb/tools/bin/DicosSyslogClient -L -m io2 -t 134.138.82.101-128 > /opt/telorb/syslog &
AD12.4 (to8/IO1):  /opt/telorb/tools/bin/DicosSyslogClient -L -d 5 -m io1 -t 134.138.81.101-128 &
AD12.4 (to8/IO2):  /opt/telorb/tools/bin/DicosSyslogClient -L -d 5 -m io2 -t 134.138.82.101-128 &

The syslog that is started on both IO processors, is located at /opt/telorb/.
By using telnet 134.138.xx.101 8000 one can change which of the detail levels
(least detailed 0 - 7 most detailed) that is to be used.

Scripts
The scripts are located at
/opt/telorb/tools/bin/
on the IO processors and look as follows on e.g. to8io1, AD12.3:

-rw-r--r--   1 telorb   telorb       523 Mar  1 10:00 BackupFormatter
-rwxr-xr-x   1 telorb   telorb       523 Feb 25 09:51 DUCK-server*
-rwxr-xr-x   1 telorb   telorb       520 Mar 24 14:00 DicosSyslogClient*
-rwxr-xr-x   1 telorb   telorb       555 Mar 28 14:25 FileServerInterpreter*
-rwxr-xr-x   1 telorb   telorb       481 Mar  6 08:52 STSsw*
-rwxr-xr-x   1 telorb   telorb       462 Feb 25 09:51 dumpd*
-rwxr-xr-x   1 telorb   telorb       457 Feb 25 09:51 ep_tftpd*
-rwxr-xr-x   1 telorb   telorb       431 Mar  7 13:06 eptee*
-rwxr-xr-x   1 telorb   telorb       421 Feb 25 09:51 ldu*
-rwxr-xr-x   1 telorb   telorb       435 Feb 25 09:51 lduReverse*
-rwxr-xr-x   1 telorb   telorb       429 Feb 25 09:51 lmRemover*
-rwxr-xr-x   1 telorb   telorb       424 Feb 25 09:51 win*

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Upgrade an LM, e.g. LM_MD44-TftpDumpd, from tos1/tos2
telnet tos1                     (Log in to the alpha machine tos1 or tos2.
                                 To be able to use the procedure below (without
                                 having to use ftp), you have to use tos1/tos2
                                 to get direct access to the IO processors)
login: telorb                   (Type user name)
Password:                       (Type password)

cd /toX/toXio1/telorb/tools/IDP_MD15-Unix     (Go to directory /opt/telorb/...
                                               on IO processor) (Adjust toX to
                                               valid TelORB system)
ls -l                           (Check status before renaming)
mv LM_MD44-TftpDumpd LM_MD44-TftpDumpd.old  (Rename the current directory
                                             LM_MD44-TftpDumpd
                                     for fallback reasons)
ls -l                           (Check status before copying)
Copy LM_MD44-TftpDumpd from e.g. AD11:
  cp -r /ipims_dicos/ipims_dicos10/dists/TelORB-AD11/system/runtime/IDP_MD15-Unix
or from a patch location
  cp -r /ipims_dicos/ipims_dicos10/dists/AD9.04-patch/official/patch11/TftpDumpd_LM/ .
ls -l                           (Check status after copying)
mv TftpDumpd_LM LM_MD44-TftpDumpd  (Rename file name TftpDumpd_LM to
                                    LM_MD44-TftpDumpd to suit the current
                                    structure)

Repeat the complete sequence above for the other IO processor (toXio2).

Either reboot the affected IO processors (i.e. both IO1 and IO2) as described
in Reboot / Power off IO processor or restart, in this
case (when TftpDumpd is to be substituted), the TftpDumpd process in both IO
processors as follows:

  On IO processor (login to IO processor):

  ps -ef | grep TftpDumpd         (Locate the TftpDumpd process and check its
                                   version)
  kill -9 <PID>                   (Kill TftpDumpd's process)

  If the related process guard is also manually killed, the killed main process
  must be started manually as follows:

    Start the killed process.     (Use the valid part of the start_services
                                   script /opt/telorb/etc/start_services on the
                                   IO processor)

  ps -ef | grep TftpDumpd         (Verify new version)


If the new LM seems to work, don't forget to remove the .old directory that was
created during the procedure above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Upgrade IDP_MD15_Unix from tos1/tos2
telnet tos1                     (Log in to the alpha machine tos1 or tos2.
                                 To be able to use the procedure below (without
                                 having to use ftp), you have to use tos1/tos2
                                 to get direct access to the IO processors)
login: telorb                   (Type user name)
Password:                       (Type password)

cd /toX/toXio1/telorb/tools     (Go to directory /opt/telorb/ on IO processor)
                                (Adjust toX to valid TelORB system)
ls -l                           (Check status before renaming)
mv IDP_MD15-Unix IDP_MD15-Unix.old  (Rename the current directory IDP_MD15-Unix
                                     for fallback reasons)
ls -l                           (Check status before copying)
cp -r /ipims_dicos/ipims_dicos10/dists/TelORB-AD7.54/system/runtime/IDP_MD15-Unix .
                                (Copy the new IDP_MD15-Unix from the
                                 distribution to the directory
                                 /opt/telorb/tools/ on the IO processor)
ls -l                           (Check status after copying)

Either reboot the affected IO processor as described in Reboot / Power off IO processor or
restart each affected process as follows:
  ls -l /ipims_dicos/ipims_dicos10/dists/TelORB-AD7.54-inc/system/runtime/IDP_MD15-Unix/
                                  (Check which LMs that are being upgraded)

  On IO processor (login to IO processor):

  ps -ef | grep x                 (Locate the process(es) that are associated
                                   with the LM(s) to be upgraded and check
                                   its/their version(s))
  kill -9 y                       (Kill the associated process(es))

  If the related process guard(s) is/are also manually killed, the killed main
  process(es) must be started manually as follows:

    Start the killed processes.   (Use the valid part(s) of the start_services
                                   script /opt/telorb/etc/start_services on the
                                   IO processor)

  ps -ef | grep x                 (Verify new version(s))


Repeat the complete sequence above for the other IO processor (toXio2).

If the new IDP seems to work, don't forget to remove the .old directory that was
created during the procedure above.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Upgrade the complete IO tools package (directory) from tos1/tos2
Either use ftp to copy the IO tools package to both IO processor's directory
/opt/telorb/ or use the alpha machine tos1/tos2 as follows:
telnet tos1                     (Log in to the alpha machine tos1 or tos2.
                                 To be able to use the procedure below (without
                                 having to use ftp), you have to use tos1/tos2
                                 to get direct access to the IO processors)
login: telorb                   (Type user name)
Password:                       (Type password)

cd /toX/toXio1/telorb/          (Go to directory /opt/telorb/ on IO processor)
                                (Adjust toX to valid TelORB system)
ls -l                           (Check status before renaming)
mv tools tools.ADxx             (Rename the current directory tools/ for
                                 fallback reasons. Preferably rename it using
                                 the release name to which it belongs, e.g. 
                                 tools.AD12.3 and keep it to be able to back to
                                 it, if needed. However, the best way, if the
                                 current directory tools/ should be kept, is to
                                 pack it (tar, gtar), to save space)
ls -l                           (Check status before copying and extracting)

Either copy the tar file or the tgz file:
  cp /ipims_dicos/ipims_dicos10/dists/TelORB-AD12.4/hwStuff/tools.tar .
                                (Copy the new tools.tar file from the
                                 distribution to the directory /opt/telorb/
                                 on IO processor)(ftp may also be used, if
                                 tos1/tos2 is not available)
    or
  cp /ipims_dicos/ipims_dicos10/dists/TelORB-AD12.4/hwStuff/tools.tgz .
                                (Copy the new tools.tgz file from the
                                 distribution to the telorb directory on
                                 IO processor)(ftp may also be used, if
                                 tos1/tos2 is not available)
  (If the IO tools package is to be fetched from a patch, the copy line will
   look something like this:
   cp /ipims_dicos/ipims_dicos10/dists/AD12.4-patch/official/patch1/tools.tar .)

ls -l
exit                            (Exit from tos1, if desired)

telnet toXio1                   (Log in to the IO processor. Adjust toX to valid
                                 TelORB system or use IP address)
login: telorb                   (Type user name)
Password:                       (Type password)
cd /opt/telorb/                 (Go to directory /opt/telorb/ on IO processor)
ls -l                           (Check that the tools tar/gtar file exists)

Either extract the tar file or the tgz file on the IO processor:
  tar xf tools.tar              (Extract tar file on current directory)
    or
  gtar xfz tools.tgz            (Extract tgz file on current directory. Requires
                                 access to gtar on IO processor)
ls -l                           (Check that the directory tools/ has been
                                 created)

Reboot the affected IO processor to activate the new IO tools package.

su                              (Enter superuser mode)
init 6  (or reboot)             (Halt and reboot (or reboot) the IO processor.
                                 The telnet connection will be closed. Be sure
                                 NOT to enter this command from tos1/tos2, if
                                 so, tos1/tos2 will be rebooted. Not necessary
                                 to sync before rebooting)

After some time it should be possible to remotely log in to the IO processor:
telnet toXio1                   (Log in to the IO processor. Adjust toX to valid
                                 TelORB system or use IP address)
login: telorb                   (Type user name)
Password:                       (Type password)

Verify that the new versions of the changed LMs in the IO tools package are
running (check the LM versions in the corresponding MI_attributes files in
directory /opt/telorb/tools/IDP_MD15-Unix/_LM_/ on the IO processor):
ps -ef                          (Verify new versions)

rm tools.tar                    (Remove tools.tar)
  and/or                          (and/or)
rm tools.tgz                    (Remove tools.tgz)
exit                            (Exit from IO processor)


Repeat the complete sequence above for the other IO processor (e.g. toXio2).

It might be good to leave the previous tools directories for a while, if testing
towards an old release has to be performed in the future.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
See DUCK server, DNS & FileServerInterpreter.

Valid tools versions for TSP 4 (TelORB R14-Linux)
 (Updated: 2003-10-28)

- tools.CXP901305.R1S01.tar was released in TSP 4.0 patch 4 (r14lp4).
    (This tools version is not completely compatible with the new IP addressing
     scheme which was introduced in TSP 4.0 patch 4.1 (EC2), since the
     /opt/telorb/etc/ep_tftpd.conf files on IO1 and IO2 will be messed up.
     These files must be manually corrected, before initial load.)

- tools.CXP901305.R1U02.tar was released in TSP 4.0 patch 5 (r14lp5).

- tools.CXP901305.R1U04.tar was released in TSP 4.0 patch 5.8 (r14lp5.8). CM cancelled.

- tools.CXP901305.R1U06.tar was released in TSP 4.0 patch 5.9 (r14lp5.9).

- tools.CXP901305.R1X01.tar was released in TSP 4.0 patch 6 (r14lp6). CM & RM cancelled.

- tools.CXP901305.R1Z02.tar was released in TSP 4.0 patch 7 (r14lp7).

- No tools package released in TSP 4.0 patch 7.1 (r14lp7.1).
- No tools package released in TSP 4.0 patch 7.2 (r14lp7.2). (Error in Delivery
                                                              Note)
- No tools package released in TSP 4.0 patch 7.3 (r14lp7.3).
- No tools package released in TSP 4.0 patch 7.4 (r14lp7.4).
- No tools package released in TSP 4.0 patch 7.5 (r14lp7.5).
- No tools package released in TSP 4.0 patch 7.6 (r14lp7.6).
- No tools package released in TSP 4.0 patch 7.7 (r14lp7.7).
- No tools package released in TSP 4.0 patch 7.8 (r14lp7.8).

- tools.CXP901305.R1Z03.tar was released in TSP 4.0 patch 7.9 (r14lp7.9).

- No tools package released in TSP 4.0 patch 7.10 (r14lp7.10).

- tools.CXP901305.R1AC02.tar was released in TSP 4.0 patch 8 (r14lp8).

To check current IO tools package version, enter the following command on the
IO processor:
  more /opt/telorb/codearchive/version

To check if a CM/RM contains a tools package release, see the Delivery Note for
the valid CM/RM at Testbed <-> CM/RM Mapping.
  (Old link: Testbed <-> CM/RM Mapping).

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Earlier versions
Info: The following LMs are included in IDP_MD15_Unix 
(/opt/telorb/tools/IDP_MD15-Unix/ on IO processor).
The versions for different ADs are fetched from each MI_attributes file:

                                     AD7.52  AD9.05.3  AD11.4.1  AD12.4  R13p10   R14     R14p2
                                     ------  --------  --------  ------  ------   ---     -----
  - /IDP_MD15-Unix/MI_attributes             R1B02     R1B21     R1B21            N/A     N/A
  - /opt/telorb/codearchive/Unix_IDP/
    UnixLib_LM/MI_attributes         N/A     N/A       N/A       N/A              R1I21   R1J
  - LM_AXG428-FileServerInterpreter  R1D02   AD905p18  R1F01     R1G01   R13p10   R1I03   R1I03
  - LM_D14-STSsw                     N/A     AD905p5   R1F02     R1G01   R1H03    R1I02   R1I02
  - LM_D3-LmRemover                  R1A01   R1E01     R1F01     R1G01   R1H02
  - LM_D35-DicosSyslogClient         N/A     N/A       R1F01     R1G01   R1H03    R1I02   R1I02
  - LM_D??-DicosApplogClient         N/A     N/A       N/A       N/A     N/A
  - LM_D46-EpTee                     N/A     N/A       N/A       R1A02   R13p9    R1I03
  - LM_MD12-DUCKServer               R1C03   R1E01     R1F01     R1G01   R1H02    R1I03   R1I03
  - LM_MD34-DataFormatter            R1B04   R1E01     R1F01     R1G01   R13p4
  - LM_MD41-EpTftpd                  R1B02   R1E01     R1F01     R1G01   R13p2    R1I03   R1I03
  - LM_MD42-LduReverse               R1B02   R1E01     R1F01     R1G01   R1E04
  - LM_MD43-Ldu                      R1B03   R1E01     R1F01     R1G03   ?
  - LM_MD44-TftpDumpd                R1B02   R1E01     R1F01     R1G01   R1H02    R1I02   R1I02
  - LM_MD45-Win                      R1B03   R1E01     R1F01     R1G01   R1H02    R1I02   R1I02
  - LM_D54-Dhcp                      ?       ?         ?         ?       R13p9    R1J05   R1J05
  - LM_D34-LduPatch                  ?       ?         ?         ?       R1H04
  - LM_D109-TransferManager          N/A     N/A       N/A       N/A     N/A      R1A11   R1A11
  - LM_D121-CrashCollector           N/A     N/A       N/A       N/A     N/A      R1A07   R1B01

LM_D46-EpTee limits the log sizes to 2Mbyte each, when using the command eptee,
for e.g. when running DicosSyslogClient.

Excerpt from "DicosSyslogClient (OU/D61, LM/D35)" (syslog):
    "The DicosSyslog was introduced in AD11 and is intended to be a better
     alternative for logging than the console printouts.
     One big improvment compared to the console printouts is that the
     DicosSyslog is common for the entire node, not per-processor as for
     the console printouts. 
     The DicosSyslogClient should run on an external processor, usually
     the IO machines, and is responsible for collecting the DicosSyslog
     messages from all TelORB processors. Many (up to 5 in AD 11)
     DicosSyslogClient may be connected to a single TelORB system."

To check the versions of all TelORB related processes executing on an IO
processor, enter the following command on an IO processor:
  ps -Af | grep telorb | grep "\./"| grep LM

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Fetch a tools package from one Linux IO processor to another
From IO processor to fetch the tools package to (e.g. to28io1):
  cd /opt/telorb/                    (Adjust path to path to fetch tools to)
  sftp 134.138.187.14                (to1io1) (Adjust to IO to fetch from)
  cd /opt/telorb/                    (Adjust path to path to fetch tools from)
  get tools.CXP901305.TSP5ED03.tar   (Adjust to valid tools package file)
  bye

General
 (Updated: 2003-11-24)

Use the official documentation "55. Kickstart Server Installation", as part of
"57. TSP 4 Installation Overview", to install the Kickstart Server.

This subchapter only contains some hints which may become useful when installing
a Kickstart Server.

Installing the Kickstart Server as part of an upgrade from TSP 4 to TSP 5 is
described in Upgrade from TSP 4 to TSP 5.

At the EAB CW/OS lab, the following machines are dedicated for Kickstart Server
usage:
- ulinpc52:    Name: ulinpc52.uab.ericsson.se     Address: 134.138.184.175
               Server:  uabs01.uab.ericsson.se    Address: 134.138.201.17

- ulinpc15:    Name: ulinpc15.uab.ericsson.se     Address:  134.138.184.215
               Server:  uabs01.uab.ericsson.se    Address:  134.138.201.17

Before starting to use any of these machines, make sure they are not being used
by anybody else.
Also be sure not to delete any Kickstart release which should be kept.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

If CD3 with the Runtime software is not available
 (Updated: 2003-11-24)

During the installation of the Kickstart Server, you will be asked for CD3,
containing the Runtime Software.
If CD3 is not available, copy the Runtime Software from the TelORB distribution
as follows and then proceed as described below:
  ssh telorb@ulinpc15      (Log in to the Kickstart Server)
  cd /home/telorb/         (You should already be here)
  sftp 134.138.187.5       (E.g. tos2)
  cd /home/dicosarc/archive/TSP4.0-patch/official/
  get TelORB-R14-Linux-Patch8.tgz
  quit

  su -
  cd /home/telorb/
  tar -C /tmp -xzvf TelORB-R14-Linux-Patch8.tgz
  ls -l /tmp/
  mv /tmp/TelORB-R14-Linux-Patch8/TelORB-R14-Linux-Patch8-Runtime/system/unix/ /tmp/
  ls -l /tmp/unix/
    The following files should be shown (revisions valid for TSP 4.0 patch 8):
      IO-KickStart-R1C05.tar
      io-upgrade-R1BtoR1C.sh
      RedHat-7.1-Upgrade-R1B01.tar
      tools.CXP901305.R1AC02.tar

  rm -rf /tmp/TelORB-R14-Linux-Patch8/
  rm TelORB-R14-Linux-Patch8.tgz
  tar -C /opt/ -xpf /tmp/unix/IO-KickStart-R1C05.tar
  tar -C /opt/ -xpf /tmp/unix/RedHat-7.1-Upgrade-R1B01.tar
  cp -a /tmp/unix/tools.CXP901305.R1AC02.tar /opt/OS/tar/
  rm -rf /tmp/unix/
  cd /opt/OS/tar/
  ln -s tools.CXP901305.R1AC02.tar tools.tar

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Run the Kickstart installation script
 (Updated: 2003-11-24)

- To run the Kickstart installation script, enter the following command:
    /opt/OS/install/ks-install.sh
- You will be prompted to insert RedHat 7.1, CD1. Press enter. ~5 min. Eject.
- You will be prompted to insert RedHat 7.1, CD2. Press enter. ~5 min. Eject.
  Press enter.
- RedHat 7.1 patches will be applied and RPMs will be installed among other
  things. ~15 min.
- You will be prompted to press enter to reboot the Kickstart Server to activate
  the new configuration.
The Kickstart Server is now installed and configured.

Also see EAB CW/OS lab specific things... below.

General
 (Updated: 2002-01-17)

This part has been updated with bits and pieces during the integration and
system test of the pre-release of "TSP 4.0 Clusterware and OS". This means that
all pieces may not be understandable to anyone else but me, but I will try to
create some order in this part as time permits.

The directory structure was changed from /opt/TSP-4.0/ to /opt/OS/ between
Drop 3.1 and Drop 3.2, e.g.
  /opt/OS/kickstart/
    ks-io-ide.cfg
    ks-io-scsi.cfg
    ks-fs-scsi.cfg
    update_ks_files

Note: The IO processors will not accept telnet as the
      log in command after TelORB release R14p7, drop 2.2.
      Use the log in command ssh instead!
      To enable the possibility to log in to an IO processor by using telnet, do
      as follows on the IO processor:
        ssh telorb@toXioY         (Adjust toX and ioY to valid IO processor name
                                   and valid IO processor number, respectively,
                                   or use the corresponding IP address instead
                                   of toXioY)
        su                        (Enter superuser mode)
        cd /etc/xinetd.d
        vi telnet                 (Set disable = no)
        /etc/init.d/xinetd restart  (Activate the new setting by restarting
                                     xinetd)
        exit                      (Exit superuser mode)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Fetch upgrade files from the distribution
 (Updated: 2002-05-03)

cd /uab/ipims_dicos/ipims_dicos10/dists/TSP4.0_no_official_use/TelORB-R14-Linux-Runtime-upto-3.3/system/unix/
Fetch the following files to the IO processor below /opt/ (revisions valid for Drop 3.3):
- IO-KickStart-P1A22-1.tar
- RedHat-7.1-Upgrade-R1A02.tar
- tools.CXP901305.R1H01.tar

== == == == == == == == == == == == == == == == == == == == == == == == == ==

EAB CW/OS lab specific things after upgrading the KickStart server files on IO2
 (Updated: 2002-05-03)

At the EAB CW/OS lab, perform the following on IO2 after upgrading the
KickStart server files on IO2.

Get gedit to work on the IO processors:
  cd /opt/OS/kickstart/
  
If you want to use gedit to edit the following files and gedit does not work, do
as follows:
  tcsh
  setenv DISPLAY 134.138.186.47:0.0

Edit the following file and save it as e.g. ks-io-ide-eth0-iov.cfg:
  gedit ks-io-ide-eth0.cfg
  After the line "@ Web Server", insert the following lines:
    @ GNOME
    @ KDE
  Repeat for the ks-io-ide-eth1.cfg file and save it as e.g.
  ks-io-ide-eth1-iov.cfg.

Update the dhcpd.pxe.conf file to use the newly updated files as follows:
  cd /opt/telorb/etc/
  gedit dhcpd.pxe.conf
  Edit the file so that the result is as follows: 
      filename "/opt/OS/kickstart/ks-io-ide-eth0-iov.cfg";
#     filename "/opt/OS/kickstart/ks-io-ide-eth0.cfg";
  :
  :
      filename "/opt/OS/kickstart/ks-io-ide-eth1-iov.cfg";
#     filename "/opt/OS/kickstart/ks-io-ide-eth1.cfg";
  :
  :
      filename "/opt/OS/kickstart/ks-io-ide-eth0-iov.cfg";
#     filename "/opt/OS/kickstart/ks-io-ide-eth0.cfg";
  :
  :
      filename "/opt/OS/kickstart/ks-io-ide-eth1-iov.cfg";
#     filename "/opt/OS/kickstart/ks-io-ide-eth1.cfg";


Now DHCP must be restarted, to activate the changes, as follows:
  ./stop_services                  (Note that RPC, NFS and NTP are also stopped)

  ./start_services 
  ./status_services

Continue to set the EAB CW/OS lab specific uid and gid as follows:
  cd /opt/telorb/etc/     New: cd /opt/OS/
  cp examples/ks_passwd.sh.uab .
  mv ks_passwd.sh.uab ks_passwd.sh

    Example of ks_passwd.sh.uab contents:
      #!/bin/bash
      # UAB I&W default users
      /usr/sbin/groupadd -g 33 uab
      /usr/sbin/groupadd -g 404 dicosadm
      /usr/sbin/groupadd -g 1024 tsp
      /usr/sbin/groupadd -g 501 telorb
      /usr/sbin/adduser -c "TSP example user" -u 1024 -g uab -G tsp -p '$1$YccSlz1Y$iLmcnH3MdMwtUpJONeIsw/' tspuser
      /usr/sbin/adduser -c "TelORB user" -u 44622 -g uab -G dicosadm,telorb -p '$1$56wE.4Uj$O4YyudQMXJBlV2WE4ooMz1' telorb

Check other files:
  more /opt/OS/extra.conf   (Check that the hostname base is correct, e.g. to24)
  more /opt/OS/IO.id        (Should be 1 on IO2)

  more /opt/telorb/etc/exports   (Must be modified later for EAB CW/OS lab
                                  tos usage)

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Upgrade BIOS on an IO or TelORB processor
 (Updated: 2001-11-02)

If BIOS is to be upgraded, follow the instructions in section
BIOS setup for Teknor Pentium III processors in a GEM cabinet.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Install/Upgrade Linux and the IO tools package on an IO processor
 (Updated: 2001-12-21)

Note: This section is only valid for installation/upgrading of Linux on IO
      processors, and not for installation/upgrading of Linux on TelORB
      processors.


Prerequisites
------------
If an existing telorb.conf file is not available for the system to be installed,
the following information must be fetched from the valid system:
- MAC addresses of the IO processors.
  To retrieve the MAC addresses of the IO processors, do as follows in a
  Carmencita system:
  o Connect a serial cable from e.g. a laptop to the serial port of the IO
    processor.
  o Use an xterm window to connect to the IO processor by entering e.g.:
      tip -9600 /dev/ttyb
    The message "connected" should appear.
  o Enter:
      .idprom
    Depending on how the IO processor is configured, either the message
    "Password:" appears (if so, just continue with the next point),
    or the following information (including the MAC (ethernet) address) appears
    (this is an example):
      "Format/Type: 1 80 Ethernet: 0 80 42 10 4b 5c Date: 1 7 19 0 
       Serial: 8c ba 47 Checksum: 2a 
       ok"
  o Press the ABORT button twice on the IO processor and verify that the "ok"
    prompt is displayed in the xterm window.
  o Type the following to retrieve the MAC (ethernet) address of the IO
    processor:
      banner
    The following information (including the MAC (ethernet) address) should
    appear (this is an example):
      "FORCE,CPCI-520(UltraSPARC-IIi 300MHz), No Keyboard
       OpenBoot 3.10.9, 256 MB memory installed, Serial #9222727.
       Ethernet address 0:80:42:10:4b:5c, Host ID: 808cba47."
  o Exit tip:
      ~.
  o Repeat for the other IO processor to obtain its MAC address.
- MAC addresses of the TelORB processors.
- Other network parameters which are necessary as input to the telorb.conf file.


Prepare the KickStart server
----------------------------
For news and info about the KickStart server, see "KickStart server info" below.

It does not matter what permissions the KickStart server directories and files
have, as long as they are readable for the user which you are logged in as.

- Make sure no one else is using the KickStart server, ulinpc52 at the EAB
  CW/OS lab.

- Log in to the KickStart server, ulinpc52 (134.138.184.175), by using e.g.
  telnet:
    ssh telorb@ulinpc52
    telorb
    psw
    cd /opt/OS/       (Old: /opt/TSP-4.0/)

- Verify that the valid KickStart version is installed on the KickStart server:
    more /opt/OS/kickstart/ks-io-ide.cfg
    Look for the following text (around line 50 from the top) (revision and
    version may not be valid in the file example):

      # Kickstart revision etc:
        :
        :
      KS_REV="P1A51"
      TSP_VERSION="TSP4, drop2.3"

  If the valid KickStart version is installed, continue below the "Upgrading of
  KickStart server end" line.
  If the valid KickStart version is not installed, the KickStart server should
  be upgraded before the IO processor installation/upgrading. This is described
  between the "Upgrading of KickStart server..." lines below.
  However, if an official upgrading instruction for the KickStart server exists,
  use that instead of following the instructions below, since my instructions
  may be outdated.


      ------------------ Upgrading of KickStart server start ------------------

      ssh telorb@ulinpc52                            (If not already performed)
      su
      cd /opt/
      mv TSP-4.0 TSP-4.0.oldX                        (Adjust X to valid version)
      Fetch the IO-KickStart and RedHat files from the valid release location
      (Adjust values):
        cp /ipims_dicos/ipims_dicos10/dists/TSP4.0/Drop2.2/IDP_D42-RH7.1_Extras/IO-KickStart-P1A11.tar .  (Adjust values)
        cp
/ipims_dicos/ipims_dicos10/dists/TSP4.0/Drop2.2/IDP_D42-RH7.1_Extras/RedHat-7.1-Upgrade-R1A01.tar .
[telorb@ulinpc52 /opt]# tar -xvpf IO-KickStart-P1A11.tar  (Adjust values)

      tar -xvpf IO-KickStart-P1A11.tar           (Adjust P1A11 to valid version)
      cd TSP-4.0

      If RPMs should be installed, do as follows:
        rpm -i RPMS/kickstart-tsp-P1A04-1.i386.rpm        (Adjust P1A04 to valid
                                                           version)
        rpm -i RPMS/pxebootstrap-P1A02-1.i386.rpm         (Adjust P1A02 to valid
                                                           version)

      Verify the contents of the /etc/dhcpd.conf file.
      It should contain the following uncommented string in the
      "shared-network snet_eth0" part:
        filename "/opt/OS/kickstart/ks-io-ide-eth0.cfg";
      or, to get some editors (at the EAB CW/OS lab):
        filename "/opt/OS/kickstart/ks-io-ide-eth0-iov.cfg"; //GNOME,KDE
      It should also contain the following uncommented string in the
      "shared-network snet_eth1" part:
        filename "/opt/OS/kickstart/ks-io-ide-eth1.cfg";
      or, to get some editors (at the EAB CW/OS lab):
        filename "/opt/OS/kickstart/ks-io-ide-eth1-iov.cfg"; //GNOME,KDE

      cp ../TSP-4.0.oldX/to*.conf .                  (Adjust X to valid version)
      cp ../TSP-4.0.oldX/extra.conf .                (Adjust X to valid version)
      cp ../TSP-4.0.oldX/ks_passwd.sh .              (Adjust X to valid version)
      cp -r ../TSP-4.0.oldX/install/pxeboot/ install/         (Adjust X to valid
                                                               version)
      Fetch the IO tools package:
        mkdir tar
        cd tar
        cp /ipims_dicos/ipims_dicos10/dists/TSP4.0/Drop2.2/tools.tar .   (Adjust
                                                          Drop2.2 to valid drop)

      Remove the current telorb.conf link, and then create a new link to the
      valid toXX-telorb.conf file:
        rm telorb.conf
        ln -s toXX-telorb.conf telorb.conf      (Adjust toXX to the name of your
                                                 TelORB system)
      exit

      At the EAB CW/OS lab, create/adjust the file /opt/OS/ks_passwd.sh on
      the KickStart server by doing the following:
        cd /opt/OS/
        cp examples/ks_passwd.sh.uab ./ks_passwd.sh

  The latest tools.tar file is located in directory /opt/OS/tar/ on the
  KickStart server. It may be OK to replace the tools.tar file separately, but
  it is not recommended, since there may be linkings between the tools contents
  and the RAM disk contents. 
 
    For further information about how to upgrade the KickStart server, see
    uabbjod's document:
    http://techdev.uab.ericsson.se/~uabbjod/TSP/html/.

      ------------------- Upgrading of KickStart server end -------------------

(If the KickStart server has not been upgraded, verify that the valid tools.tar
 file is located in directory /opt/OS/tar/.) 

- Edit the valid /opt/OS/toXX-telorb.conf file, so that it suits the TelORB
  system for which the IO processor is to be installed/upgraded. (Adjust toXX to
  valid system.) Or copy the /opt/telorb/etc/telorb.conf file from any of the IO
  processors, i.e. if that telorb.conf file is valid.

  Preferably check if the telorb.conf template and example files have changed.
  If there are changes, these changes should be implemented in the
  toXX-telorb.conf file.
  One way of doing this, is to unpack tools.tar and comparing its
  telorb.conf.example file with the valid toXX-telorb.conf file as follows:
    su                                       (Enter superuser mode)
    psw                                      (Enter password)
    mkdir /opt/OS/tmp/                       (Create a temporary directory)
    cd /opt/OS/tmp/
    cp /opt/OS/tar/tools.tar .               (Copy the valid tools.tar file)
    tar xf tools.tar                         (Unpack the fetched tools.tar file)
    cd codearchive/iom_scripts/
    more telorb.conf.example
    more /opt/OS/toXX-telorb.conf       (Adjust toXX to valid system)
    Compare the telorb.conf.example file with the valid toXX-telorb.conf file.
    If there are changes, edit the telorb.conf file accordingly.
    cd ..
    rm -rf tmp/                              (Remove the tmp/ directory)

- "Activate" your /opt/OS/toXX-telorb.conf file on the KickStart server by
  changing the link as follows:
    If your toXX-telorb.conf file is not located at /opt/OS/, copy or move
    it there.                                      (Adjust toXX to valid system)
    rm telorb.conf
    ln -s toXX-telorb.conf telorb.conf             (Adjust toXX to valid system)
    ls -l telorb.conf                          (Verify that the link is correct)

- Check/Edit the /opt/OS/IO.id file, so that it matches the number of the
  target IO processor (1 or 2) to install Linux on:
    more IO.id
    Edit the file, if it does not match the number of the target IO processor.

- Edit the /opt/OS/extra.conf file, so that the line "hostname base toXX"
  mathes your system, e.g. to28:
    (Must be superuser to edit the file)
    more extra.conf
    Edit the file, if it does not match your system.

- Verify that the KickStart server will install Linux (not upgrade BIOS) by
  checking/editing the /etc/pxe.cf file (linked to /opt/telorb/etc/pxe.cf)
  (Must be superuser to edit the file):
    cd /etc/
    more pxe.cf

      The "Menu string..." part of the /etc/pxe.cf file should look as follows:
 
        # Menu string that will be displayed on the client screen
        # after F8 is pressed.
        [X86PC/UNDI/MENU]
        13,Default                       <---- This line must be "13,Default"
        13,Remote Install Linux
        14,DOSUNDI
        0,Local Boot

    (If "14,Default" is used, BIOS will be upgraded.)

- If the pxe.cf file is changed, the affected program should be restarted as
  follows (as superuser):
    cd /etc/rc3.d/
    ./S56pxe stop
    ./S56pxe start
    exit                      (Exit superuser mode)

(Add somewhere in Kickstart server subchapter: /opt/OS/ks_passwd.uab)


Install Linux on IO processor
-----------------------------

- Verify that the installation magazine (EAB CW/OS lab specific) is
  connected to the KickStart server from the 100BaseTx port on the right-most
  SCB board in the installation magazine.
  (At the EAB CW/OS lab, the installation magazine is a dedicated magazine
  for installation/ upgrading of Linux and for upgrading of BIOS in processors.)

- If the target IO processor, where Linux will be installed, is located in a
  TelORB system, halt the target IO processor (from an IO processor shell),
  before removing it from the magazine:
    su                                                   (Enter superuser mode)
    psw                                                  (Enter password)
    /sbin/halt                                           (Halt the IO processor)
                           (Sometimes it is necessary to enter /sbin/halt twice)

- Insert the target IO processor in the installation magazine (EAB CW/OS lab
  specific).

- Connect a serial cable with a null modem from e.g. an IO processor (where the
  terminal program (tip or minicom) will be started) to the target IO processor.

- Open an xterm window on your workstation and log in to e.g. the IO processor
  where the terminal program will be started by using e.g. ssh (or telnet).

- To start the terminal program, enter the following commands in the xterm
  window:
    If the IO processor, to start the terminal program on, is running with
    Linux OS:
      su                     (Enter superuser mode, if not already done)
      psw                    (Enter password)
      minicom ttyS0      (Start minicom session on the previously defined ttyS0)

    (For further information about how to use minicom, see
     Connect to remote host using "minicom".)

    If the IO processor, to start the terminal program on, is running with
    Solaris OS:
      su                     (Enter superuser mode)
      psw                    (Enter password)
      tip -38400 /dev/ttyb   (Connect to target processor, possibly adjust the
                              speed and/or ttyb)

    (For further information about how to use tip, see
     Connect to remote host using "tip".)

- Reboot the target IO processor by e.g. pressing its reset button and perform
  the next step as soon as possible after the reboot is started.

- In the xterm window, press the Del (or backspace) key to enter the BIOS setup
  menu. (The current BIOS version is printed.)

- Go to the "BIOS FEATURES SETUP" menu ("Virus Protection, Boot Sequence...") by
  pressing `arrow down' once and Enter.

- Select "Boot From LAN First" by pressing `arrow down' 4 times.

- Change the BIOS boot location to "LAN 2-1" by pressing the + (plus)
  or - (minus) key. (Also works with "LAN 2").

- Quit the "BIOS FEATURES SETUP" menu by pressing Esc.

- Go to the "SAVE & EXIT SETUP" menu ("Save Data to CMOS & Exit SETUP") by
  pressing `arrow up' 3 times and Enter.

- Answer `y' (Yes) to the question "SAVE to CMOS and EXIT (Y/N)?" and press
  Enter.

- The Linux installation will now start automatically and it will take
  approximately 27 minutes. ("Install System" should be visible in the upper
  right corner when the installation has started (after the booting phase).
  After a while, it will change to "IO-install".)
    (If the installation does not start, there may be a problem with the PXE
    server running on the KickStart server (/usr/local/lib/Pxe_LM/bin/Pxe.LM) or
    the DHCP server.
    It may be worthwhile to restart the PXE server on the KickStart server
    (ulinpc52) as follows:
       ps -ef | grep Pxe             (Look for /usr/local/lib/Pxe_LM/bin/Pxe.LM)
       cd /etc/init.d/
       su                                                 (Enter superuser mode)
       psw                                                (Enter password)
       ./pxe restart                                      (Restart PXE server)
         or, if the PXE server is not running:
           ./pxe start                                    (Start PXE server)
       ps -ef | grep Pxe             (Look for /usr/local/lib/Pxe_LM/bin/Pxe.LM)
       exit                                               (Exit superuser mode)

    It may be worthwhile to restart or start the DHCP server on the KickStart
    server (ulinpc52) as follows:
       ps -ef | grep dhcpd                         (Look for /usr/sbin/dhcpd...)
       cd /etc/init.d/
       su                                                 (Enter superuser mode)
       psw                                                (Enter password)
       ./dhcpd restart                            (Restart or start DHCP server)
       ps -ef | grep dhcpd                         (Look for /usr/sbin/dhcpd...)
       exit                                               (Exit superuser mode))

- Wait for the following installation printouts:

               "Installation Complete"
                     "Complete"
    "Congratulations, installation is complete."

- Press Enter to reboot the target IO processor. Perform the next step as soon
  as possible after the reboot is started, but not before "Memory Test :" is
  received.

- Press the Del (or backspace) key to enter the BIOS setup menu.

- Go to the "BIOS FEATURES SETUP" menu ("Virus Protection, Boot Sequence...") by
  pressing `arrow down' once and Enter.

- Select "Boot From LAN First" by pressing `arrow down' 4 times.

- Change the BIOS boot location to "None" by pressing the + (plus)
  or - (minus) key.

- Quit the "BIOS FEATURES SETUP" menu by pressing Esc.

- Go to the "SAVE & EXIT SETUP" menu ("Save Data to CMOS & Exit SETUP") by
  pressing `arrow up' 3 times and Enter.

- Answer `y' (Yes) to the question "SAVE to CMOS and EXIT (Y/N)?" and press
  Enter.

- The installation is completed.

- Let the target IO processor perform a complete reboot, to verify that the
  processor reboots correctly and to make it possible to halt the processor
  before removing it from the installation magazine. (There are other ways, if
  you are fast enough.)

- Wait until the printout "Starting crond: [  OK  ]" is received.

- Halt the target IO processor by pressing Enter and then at the login prompt:
    telorb                                          (Or log in directly as root)
    psw
    su
    psw
    /sbin/halt

- Remove the target IO processor from the installation magazine and insert it in
  the target TelORB system.
  If possible, keep the serial cable connected to the target IO processor, to be
  able to see the reboot phase, when the IO processor is rebooting in the target
  TelORB system.

- EAB CW/OS lab specific:
  After the IO processor has been inserted in the TelORB system, it should be
  physically connected to the EAB CW/OS lab network "Pink-LAN" (134.138.187)
  (to be able to ssh into the IO processor from the EAB CW/OS lab environment.)

- If any of the TelORB processors are equipped with two ethernet interfaces on
  the front of the board (i.e. eth2 and eth3), these interfaces along with some
  vip-network settings should have been defined for each of these boards in the
  telorb.conf file.
  For some reason, this information is not copied to the dhcpd.pxe.conf file.
  Therefore, verify if the vip-network settings exist in the dhcpd.pxe.conf file
  below the heading "# define virtual-ip network" as follows:
    Log in to the IO processor by using the command ssh.
    cd /opt/telorb/etc/
    more dhcpd.pxe.conf
  If no vip-network settings exist, these must be manually defined in the
  dhcpd.pxe.conf file as follows (3 boards, adjust IP addresses if necessary):
    # define virtual-ip network
       subnet 192.168.63.4 netmask 255.255.255.252 {
       }
       subnet 192.168.64.4 netmask 255.255.255.252 {
       }

       subnet 192.168.63.8 netmask 255.255.255.252 {
       }
       subnet 192.168.64.8 netmask 255.255.255.252 {
       }

       subnet 192.168.63.12 netmask 255.255.255.252 {
       }
       subnet 192.168.64.12 netmask 255.255.255.252 {
       }
  I have issued TR UABtr06601 for this.

- If no further IO processors will be installed/upgraded, end either the minicom
  session by entering
    Ctrl-a x
    Yes
  or end the tip session by entering
    ~. (tilde and full stop).

- EAB CW/OS lab specific (to make it possible to use tos1/tos2 later):
  When the target IO processor has rebooted, log in to it by using the command
  ssh.

  Update the file /opt/telorb/etc/exports, i.e. the following string should be
  added at the end of the "/opt/telorb" line in the exports file:
    134.138.184.0/255.255.248.0(rw)
  Thereafter, activate the exports file settings, by restarting the NFS server:
    su                                                    (Enter superuser mode)
    psw                                                   (Enter password)
    /etc/rc3.d/S15nfs restart                             (Restart NFS server)
    exit                                                  (Exit superuser mode)

  This step is also described in section
  IO processor software upgrade (tools).

- Verify that NFS server, DHCP server and TelORB services are running:
      ps -ef | grep nfs
        or
      /usr/sbin/exportfs
      
      /opt/telorb/etc/status_dhcp

      /opt/telorb/etc/status_services

- Verify that the correct KickStart version has been installed on the IO
  processor and also verify the IO processor ID:
    cat /etc/version   (gives the RAM disk version)

- Verify the IO tools package version:
    more /opt/telorb/codearchive/version

- If the other IO processor in the same system should be installed/upgraded,
  change the /opt/OS/IO.id file on the KickStart server to point to the
  other IO processor, and thereafter continue at "Install Linux on IO processor"
  above.

- When both IO processors in a TelORB system have been installed/upgraded,
  continue to follow the "Shortcut instructions", points 16-21, in section
  IO processor software upgrade (tools).

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check version of KickStart on IO processor
 (Updated: 2001-11-19)

cat /etc/version   (gives the RAM disk version)

  Example of printout (for TSP 4.0, Drop 2.3):
    KickStart-Name: ks-io-ide-eth1.cfg
    KickStart-PN:   1/XXX 000 000
    KickStart-Rev:  P1A51
    IOprocessor-ID: 1

uname -a

  Example of printout (for an early release in TSP 4.0):
    Linux to27io2.uab.ericsson.se 2.4.17-R1A17 #1 Tue Apr 30 13:30:15 CEST 2002 i686 unknown

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Files in directory /etc/rc3.d/
 (Updated: 2001-12-21)

The following files should exist in directory /etc/rc3.d/ after the
installation/upgrading of an IO processor for TSP 4.0, drop 2.3:

lrwxrwxrwx    1 root     root           17 Jan  1  1999 S10network -> ../init.d/network
lrwxrwxrwx    1 root     root           16 Jan  1  1999 S12syslog -> ../init.d/syslog
lrwxrwxrwx    1 root     root           17 Jan  1  1999 S13portmap -> ../init.d/portmap
lrwxrwxrwx    1 root     root           17 Jan  1  1999 S14nfslock -> ../init.d/nfslock
lrwxrwxrwx    1 root     root           29 Dec 21 17:10 S15nfs -> /etc/rc.d/rc3.d/../init.d/nfs
lrwxrwxrwx    1 root     root           18 Jan  1  1999 S17keytable -> ../init.d/keytable
lrwxrwxrwx    1 root     root           14 Dec 21 17:00 S26ntpd -> ../init.d/ntpd
lrwxrwxrwx    1 root     root           25 Dec 21 17:10 S34Dhcp_isc -> /etc/rc.d/init.d/dhcp_isc
lrwxrwxrwx    1 root     root           14 Jan  1  1999 S55sshd -> ../init.d/sshd
lrwxrwxrwx    1 root     root           16 Jan  1  1999 S56xinetd -> ../init.d/xinetd
lrwxrwxrwx    1 root     root           13 Dec 21 17:00 S60nfs -> ../init.d/nfs
lrwxrwxrwx    1 root     root           23 Dec 21 17:00 S84kickstart-tsp -> ../init.d/kickstart-tsp
lrwxrwxrwx    1 root     root           31 Dec 21 17:10 S88TelorbServices -> /etc/rc.d/init.d/TelorbServices
lrwxrwxrwx    1 root     root           15 Jan  1  1999 S90crond -> ../init.d/crond
lrwxrwxrwx    1 root     root           11 Jan  1  1999 S99local -> ../rc.local

Use the following command to remove unnecessary files, if any (adjust the
parameters so that none of the files above are removed):
  rm `ls | egrep -v
"^S..network|^S..syslog|^S..portmap|^S..nfs*|^S..keytable|^S..ntpd|^S..Dhcp_isc ^S..sshd|^S..xinetd|S..TelorbServices|^S..crond|^S..local"`

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Syslog
 (Updated: 2003-08-29)

Restart the syslog located in /var/log/:
  su
  /etc/initd.syslog restart

To remove the syslog, i.e. before CM449 in TSP4 when the syslog consisted of
only one file (i.e. file "syslog" in directory /var/log/), do as follows:
  su
  cd /var/log/
  rm syslog
  /etc/init.d/syslog restart   (A new fresh syslog file will be started) 

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
 (Updated: 2001-11-02)

- Verify that the latest RAM disk contents (mktpfs-<version>.tar) is
  located in directory /opt/OS/tar/ on the KickStart server:
    cd /opt/OS/tar/
    ls -l                                  (or ls -l /opt/OS/tar/)

  If not (not recommended if you do not know what you are doing):
    Copy the valid mktpfs-P1AYY.tar file to /opt/OS/tar/.  (Adjust P1AYY to
                                                            valid version)
    gzip -9 mktpfs-P1AYY.tar               (mktpfs-P1AYY.tar.gz will be created)
    cd /opt/OS/

   Edit the ks.cfg file so that the line 
    "/bin/tar -C /opt -zxf $MNT/$PKGDIR/tar/mktpfs-P1AYY.tar.gz"
    below the heading "Install ramdisk-tools" gets the valid RAM disk version.

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

Create telorb user for the EAB CW/OS lab environment
In the EAB CW/OS lab environment we use uid=44622 and gid=33.
At a customer site they have different uid and gid values (e.g. after kickstart
installation 2003-03-28 TSP 4.1 (uid=user id, gid=group id):
uid=101(telorb) gid=501(telorb) groups=501(telorb),100(users))
and this is taken care of when the prepare(?) script is being executed later.
(The script will not overwrite the values which are set in this section.)
(Later, when building the system, the uid and gid must be the same in the epct
file, where the file system data is specified, as the uid and gid for the IO
processors. The uid and gid are received in the IO processors when kickstarting
them.)

It does not matter in which directory you are when performing the following:
  su                                (Become root)
  /usr/sbin/groupadd -g 33 telorb   (Add telorb group)
  /usr/sbin/useradd -u 44622 -g telorb -s /bin/tcsh telorb     (Add telorb user)
  passwd telorb                     (Enter a password for the telorb user twice)
  passwd                            (Enter a password for the root user twice)

Linux specific files

/opt/telorb/etc/pxe.cf               (Points at plPXE.0 and plPXE.1)
                                     (Specifies which TelORB processor that
                                      runs on Linux OS)

/tftpboot/X86PC/UNDI/
  drwxrwxr-x    2 telorb   telorb       4096 May 13 11:44 Dicos
  drwxrwxr-x    2 telorb   telorb       4096 May 13 11:41 linux-install
  drwxrwxr-x    2 telorb   telorb       4096 Oct 14 18:32 linux-tp

/tftpboot/X86PC/UNDI/Dicos/
  -rwxrwxr-x    1 telorb   telorb       9045 Oct 11 16:02 plPXE.0
  -rwxrwxr-x    1 telorb   telorb     432052 Oct 11 16:02 plPXE.1

    plPXE.0   (Bootstrap loading, PXE loading)
    plPXE.1   (Linux OS) (Corresponds to plLoadable)
    (plPXE.2   (RAM disk) (Only on Linux IO processors)
              (Files unreadable with `more')

-- -- --

Linux RAM disk (R14lp8-pre1) (Updated: 2003-10-28):
cd /tftpboot/X86PC/UNDI/linux-tp/
-rwxrwxr-x    1 telorb   telorb      13136 Oct 23 16:00 linux.0
-rwxr-xr-x    1 telorb   uab        966139 Oct 28 09:16 linux.1
-rwxr-xr-x    1 telorb   uab      14464603 Oct 28 09:16 linux.2

-- -- --

Check Linux RAM disk version (Updated: 2003-10-28):
  Log in to Linux processor (either Telorb processor or IO).
  uname -a

-- -- --

ifconfig -a

/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
/etc/sysconfig/network-scripts/ifcfg-eth2
/etc/sysconfig/network-scripts/ifcfg-eth3

  Example of contents of /etc/sysconfig/network-scripts/ifcfg-ethX for R14lp7
  (CM447&CM448):
    more /etc/sysconfig/network-scripts/ifcfg-eth0
    # internal-network subnet0, BIOS LAN1, Left SCB.
    DEVICE=eth0
    BOOTPROTO=static
    IPADDR=172.16.0.129
    NETMASK=255.255.248.0
    ONBOOT=yes
    #GATEWAY=172.16.0.31

    more /etc/sysconfig/network-scripts/ifcfg-eth1
    # internal-network subnet1, BIOS LAN2, Right SCB.
    DEVICE=eth1
    BOOTPROTO=static
    IPADDR=172.16.8.129
    NETMASK=255.255.248.0
    ONBOOT=yes
    #GATEWAY=172.16.8.31

    more /etc/sysconfig/network-scripts/ifcfg-eth2
    # external-network subnet0, eth2, Lower Front Panel interface.
    DEVICE=eth2
    BOOTPROTO=static
    IPADDR=134.138.83.118
    NETMASK=255.255.248.0
    ONBOOT=yes
    GATEWAY=134.138.80.1

/etc/sysconfig/network
  Example of contents (EAB CW/OS lab specific before R14lp7 (CM447&CM448)):
    NETWORKING=yes
    HOSTNAME=to28io1.uab.ericsson.se
    GATEWAY=134.138.184.1

  Example of contents (EAB CW/OS lab specific after R14lp7 (CM447&CM448)):
    NETWORKING=yes
    HOSTNAME=to28io1.uab.ericsson.se

  Example of contents after kickstart installation:
    NETWORKING=yes
    HOSTNAME=io1.localdomain

  In R14lp7 and onwards, the network file should be considered as a global file,
  and should not be altered, except for at the EAB CW/OS lab where the
  hostname of the IO processor may be inserted.
  The valid TSP specific data should be specified in the ifcfg-ethX files.
  (The file name may be misleading. It is the contents of the ifcfg-ethX files
   that decides which eth they are valid for (DEVICE=ethX).) 

Modify the hostname of an IO processor after kickstart installation:
  - Modify the /etc/sysconfig/network file from e.g.
      NETWORKING=yes
      HOSTNAME=io1.localdomain
    to e.g.
      NETWORKING=yes
      HOSTNAME=to28io1.uab.ericsson.se

  - Modify the file /etc/hosts from e.g.
      # Do not remove the following line, or various programs
      # that require network functionality will fail.
      127.0.0.1               localhost.localdomain localhost
      172.16.0.129    io1net0.localdomain io1.localdomain io1 io1net0
      172.16.8.129    io1net1.localdomain io1.localdomain io1 io1net1
      172.16.9.1      io2net1.localdomain io2.localdomain io2 io2net1
      172.16.1.1      io2net0.localdomain io2.localdomain io2 io2net0
    to e.g.
      # Do not remove the following line, or various programs
      # that require network functionality will fail.
      127.0.0.1		localhost.localdomain localhost
      172.16.16.129 	to28io1net0.uab.ericsson.se to28io1.uab.ericsson.se to28io1 io1 to28io1net0 io1net0
      172.16.24.129 	to28io1net1.uab.ericsson.se to28io1.uab.ericsson.se to28io1 io1 to28io1net1 io1net1
      172.16.25.1 	to28io2net1.uab.ericsson.se to28io2.uab.ericsson.se to28io2 io2 to28io2net1 io2net1
      172.16.17.1 	to28io2net0.uab.ericsson.se to28io2.uab.ericsson.se to28io2 io2 to28io2net0 io2net0

Modify the external IP address (eth2) after kickstart installation:
  - Modify the IP address and possibly also the gateway address in the file
    /etc/sysconfig/network-scripts/ifcfg-eth2 from e.g.
      # external-network subnet0, eth2, Lower Front Panel interface.
      DEVICE=eth2
      BOOTPROTO=static
      IPADDR=134.138.83.118
      NETMASK=255.255.248.0
      ONBOOT=yes
      GATEWAY=134.138.80.1
    to e.g.
      # external-network subnet0, eth2, Lower Front Panel interface.
      DEVICE=eth2
      BOOTPROTO=static
      IPADDR=134.138.187.113
      NETMASK=255.255.248.0
      ONBOOT=yes
      GATEWAY=134.138.184.1

  - Modify the IP address and possibly also the gateway address in the file
    /opt/telorb/telorb.conf and thereafter execute the following configuration
    script:
      /opt/telorb/codearchive/iom_scripts/configureTelORB.sh

  - Activate the new network settings by either restarting the IO processor or
    by entering the following command:
      /sbin/services network restart

/etc/group
/etc/passwd

/var/log/messages                    (Logs everything that is done on the IO)

/var/log/kernel

/usr/bin/ksymoops

Error dumps on Linux TPs:
oops = Linux core error dump (ksymoops may be used to interpret these)
core = Application crash (gdb may be used to interpret these)
       E.g. core.t1051025645.u0.g0.eu0.eg0.n0.p1614.java.gz.172.16.0.5-1167.

Create a telorb and etc directory
  cd /opt/
  mkdir telorb                      (Create a telorb directory below /opt/)
  chgrp telorb telorb
  chown telorb telorb
  date
  date -s "Fri Oct  5 12:40:30 CET 2001"
  exit                              (Exit from su)
  exit                              (Logout from the ssh session)
  ssh telorb@to25io1                (Log in to IO processor)
  telorb                            (Become telorb user)
  cd telorb
  mkdir etc                         (Create an etc directory below /opt/telorb/)


Fetch and unpack the IO tools package and the rest
See instructions in section "IO processor software upgrade (tools)" for TelORB
R13, section "Fetch and unpack the IO tools package" and onwards. 

== == == == == == == == == == == == == == == == == == == == == == == == == ==

KickStart server info
 (Updated: 2001-10-29)

Installation of the Kickstart server with Linux RedHat 7.1 and TelORB Runtime
should be done by connecting a PC monitor, keyboard and mouse directly to the
Kickstart server, e.g. ulinpc52 or ulinpc15.
When connecting the mouse, it may not instantly work. If so, do as follows:
- Type Ctrl-Alt-F6 (enter text mode).
- Type Ctrl-Alt-F7 (enter graphical mode).
Now the mouse will work.
This problem is fixed in later RedHat releases (than 7.1).

News in IDP_D42-P1A24 (Source: e-mail from Stefan Björnelund, 2001-10-29)
---------------------
- exctra.conf: NTPSERVERS removed, use timeserver in telorb.conf (for external
  NTP-servers) (IO-boards are automatically configured as NTP servers, i.e. no
  configuration is necessary for this)
- mktpfs.sh: /boot/linux_initrd.img.gz -> /tftpboot/.../linux-tp/linux_initrd.img.gz.new
- cronjob to restart xinetd every 5 minutes (on IO)
- extra.conf:basename gives a correct /etc/hosts file
- TP:syslogd logs data on IO1

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints
 (Updated: 2001-10-05)

Reboot IO processor
  /sbin/reboot

Halt IO processor

  /sbin/shutdown -h now                   (Halt IO processor immediately without
                                           printout)
    or
  /sbin/shutdown -h +1 "transport"        (Halt IO processor after 1 min. with
                                           printout)
    or
  su
  /sbin/halt


Check hardware statuses on ethernet interfaces on IO processor
/sbin/mii-tool

If building does not work via tos1/tos2
Check contents of /opt/telorb/etc/exports.
If content is not .... correct the exports file and stop and start
the NFS server (`S15nfs stop', `S15nfsstart') (`S15nfs restart' is
not enough).

Check which version of the tsp script that is running
rpm -qa --define '_dbpath /opt/telorb/rpmdb'
TspScripts-R1A06-1


/opt/telorb/tsp/
/opt/telorb/tsp/

/var/opt/telorb/tsp/   Where everything is copied to from /opt/telorb/tsp/ and
                       is executed from. /var/opt/telorb/... is only used for
                       diskless processors. No longer valid???

To activate the /opt/telorb/tsp/tsp.conf file, restart tsp:
  su -
  cd /opt/telorb/tsp/
  ./tsp stop
  ./tsp start


Check activities on IO processor as they appear
  su
  tail -f /var/log/messages                                (Ctrl-c to stop tail)


Get a log about what has happened in a Linux processor
Note that the logs mentioned below will be cleared at a processor reload.

  telnet 134.138.xx.yyy                    (Adjust xx and yyy to valid network
                                           address and Linux processor address)
  telorb                                   (Log in as telorb user)
  psw                                      (Enter password)
  cd /tmp/
  more tsp_console.log                     (Print the tsp_console.log file)
  more tsp_startup_log.txt                 (Print the tsp_startup_log.txt file)
  tail 100 /tmp/tsp_console.log            (Print the last 100 lines in
                                            /tmp/tsp_console.log)

To constantly get Linux processor printouts, tail the tsp_console.log file as
follows (the tail command will of course be broken at a processor reload):
  cmdtool -Wl "ToX - ProcessorY"           (Open a new shell window with the
                                            name "ToX - ProcessorY") (Not
                                            necessary)
  From the new shell window:
    telnet -l telorb 134.138.xx.yyy        (telnet to Linux processor
    tail -f /tmp/tsp_console.log           (Start tail)
                                           (Ctrl-c to stop tail)


Log in to a TelORB processor with Linux OS
  ssh -x -l tspuser 134.138.xx.103
  Use the tspuser password to log in.
This only works if the TelORB processor runs with Linux OS.
  Type exit to exit.


Make it possible to log in to an IO processor using ftp
On the IO processor where ftp access should be enabled:
  su
  psw 
  Comment the last three lines in the file /etc/ftpaccess so that the file looks
  something like this:
	class dicos real *
	noretrieve
	loginfails 5
	rivate no
	email root@localhost
	message /welcome.msg    LOGIN
	message .message        CWD=*
	readme  README* LOGIN
	readme  README* CWD=*
	chmod   no      anonymous,guest
	delete  no      anonymous
	overwrite       no      anonymous
	rename  no      anonymous
	passwd-check    rfc822  warn
	log transfers anonymous,guest,real inbound
	log transfers anonymous,guest,real outbound

	# instead of /etc/ftpusers
	#deny-gid %-99 %65535                        <--- Uncomment this line
	#deny-uid %-99 %65535                        <--- Uncomment this line
	#allow-gid telorb                            <--- Uncomment this line


Put a file on an IO processor
  sftp telorb@<IP address of IO>
    (Here you may get the question "...continue connecting (yes/no)?".
     Answer yes.)
  Password:
  Go to where to put the file, using cd.
  put <file_name>
  quit


Log in from an IO processor to e.g. another IO processor and get or put a file
Log in:
  sftp toXXioY              (or use IP address)
  <telorb_password>

Get a file:
  get <file_name>

Put a file:
  put <file_name>

Quit sftp:
  quit


Initial load, zone reload and processor reload sometimes fail due to hanging TFTP
The processors which will not load stop when trying to get tftpd, i.e. a
printout like the following is received:

  "Auto-select:                                                                   
        Linux pxe boot [34, 34, 33, 33]
                                                                               
   BOOT SERVER IP: 134.138.62.25
   PXE-E32: TFTP open timeout
   TFTP..."

The problem disappears when xinetd is restarted as described below.
 
  On IO processor:
    su                                       (Enter superuser mode)
    psw                                      (Enter password)
    cd /etc/rc.d/init.d                      (Got o where xinetd is located)
    ./xinetd restart                         (Restart xinetd)
    exit                                     (Exit superuser mode)
    ps -ef | grep xinetd                     (Verify that xinetd is executing)
      (root     14810     1  0 02:43 ?        00:00:00 xinetd -stayalive -reuse -pidfil)

Initial load, zone reload and processor reload sometimes fail due to hanging TFTP on IO
 (Updated for TSP 5.0: 2004-02-09)

Try different settings in the file /etc/xinetd.d/tftp.
Example of contents for TSP 5.0 LSV8pre:
    Converted by inetdconvert
    service tftp
    {
	socket_type		= dgram
	protocol		= udp
	wait			= no
	user			= root
	server			= /usr/sbin/in.tftpd
        server_args             = -s /opt/telorb/axe/loadingGroup01_1
	disable			= no
    }

Restart xinetd (other processes will also be affected): 
  /etc/rc.d/init.d/xinetd restart

Enter:
  netstat -an
Example of printout:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:7008          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:32768           0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7009          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7010          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:52994           0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7011          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:59428           0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7012          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7013          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7014          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:873             0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:44975           0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:44976           0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7001          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7002          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:32858           0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:731             0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7003          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:6011          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7004          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:5500            0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:6012          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7005          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:6013          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7006          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:6014          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:7007          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:6015          0.0.0.0:*               LISTEN      
tcp        0      0 172.16.16.129:52997     172.16.16.19:30630      ESTABLISHED 
tcp        0      0 172.16.16.129:52996     172.16.16.17:30630      ESTABLISHED 
tcp        0      0 172.16.16.129:53000     172.16.16.7:30630       ESTABLISHED 
tcp        0      0 172.16.16.129:52995     172.16.16.15:30630      ESTABLISHED 
tcp        0      0 172.16.16.129:53001     172.16.16.9:30630       ESTABLISHED 
tcp        0      0 172.16.16.129:60933     172.16.16.23:30630      ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:43570         ESTABLISHED 
tcp        0      0 127.0.0.1:6013          127.0.0.1:59426         ESTABLISHED 
tcp        0      0 127.0.0.1:6013          127.0.0.1:40277         ESTABLISHED 
tcp        0      0 127.0.0.1:6015          127.0.0.1:32852         ESTABLISHED 
tcp        0      0 172.16.16.129:53002     172.16.16.137:30630     ESTABLISHED 
tcp        0      0 172.16.16.129:52998     172.16.16.139:30630     ESTABLISHED 
tcp        0      0 172.16.16.129:60897     172.16.16.9:10000       ESTABLISHED 
tcp        0      0 127.0.0.1:59426         127.0.0.1:6013          ESTABLISHED 
tcp        0      0 172.16.16.129:59428     172.16.16.137:49273     ESTABLISHED 
tcp        0      0 172.16.24.129:52993     172.16.24.137:30330     ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:44456         ESTABLISHED 
tcp        0      0 127.0.0.1:7010          127.0.0.1:45019         ESTABLISHED 
tcp        0      0 127.0.0.1:7008          127.0.0.1:45016         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45012         ESTABLISHED 
tcp        0      0 127.0.0.1:7011          127.0.0.1:45023         ESTABLISHED 
tcp        0      0 127.0.0.1:7012          127.0.0.1:45022         ESTABLISHED 
tcp        0      0 127.0.0.1:7013          127.0.0.1:45021         ESTABLISHED 
tcp        0      0 127.0.0.1:7007          127.0.0.1:45020         ESTABLISHED 
tcp        0      0 127.0.0.1:7001          127.0.0.1:45011         ESTABLISHED 
tcp        0      0 127.0.0.1:45024         127.0.0.1:7014          ESTABLISHED 
tcp        0      0 127.0.0.1:7006          127.0.0.1:45010         ESTABLISHED 
tcp        0      0 127.0.0.1:45021         127.0.0.1:7013          ESTABLISHED 
tcp        0      0 127.0.0.1:7003          127.0.0.1:45009         ESTABLISHED 
tcp        0      0 127.0.0.1:45022         127.0.0.1:7012          ESTABLISHED 
tcp        0      0 127.0.0.1:7002          127.0.0.1:45008         ESTABLISHED 
tcp        0      0 127.0.0.1:45023         127.0.0.1:7011          ESTABLISHED 
tcp        0      0 127.0.0.1:7005          127.0.0.1:45015         ESTABLISHED 
tcp        0      0 127.0.0.1:45540         127.0.0.1:6013          ESTABLISHED 
tcp        0      0 127.0.0.1:45019         127.0.0.1:7010          ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45018         ESTABLISHED 
tcp        0      0 127.0.0.1:7004          127.0.0.1:45014         ESTABLISHED 
tcp        0      0 127.0.0.1:7009          127.0.0.1:45013         ESTABLISHED 
tcp        0      0 127.0.0.1:45013         127.0.0.1:7009          ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45017         ESTABLISHED 
tcp        0      0 127.0.0.1:45016         127.0.0.1:7008          ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:44999         ESTABLISHED 
tcp        0      0 127.0.0.1:43570         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:44998         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:44997         ESTABLISHED 
tcp        0      0 127.0.0.1:44998         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:44999         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:44997         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45002         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45003         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45000         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45001         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45006         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45007         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45004         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45005         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45012         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45018         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:45017         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:44456         127.0.0.1:6010          ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45007         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45006         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45005         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45004         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45003         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45002         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45001         ESTABLISHED 
tcp        0      0 127.0.0.1:6010          127.0.0.1:45000         ESTABLISHED 
tcp        0      0 127.0.0.1:40277         127.0.0.1:6013          ESTABLISHED 
tcp        0      0 127.0.0.1:45020         127.0.0.1:7007          ESTABLISHED 
tcp        0      0 127.0.0.1:45010         127.0.0.1:7006          ESTABLISHED 
tcp        0      0 127.0.0.1:45015         127.0.0.1:7005          ESTABLISHED 
tcp        0      0 127.0.0.1:45014         127.0.0.1:7004          ESTABLISHED 
tcp        0      0 127.0.0.1:6013          127.0.0.1:45540         ESTABLISHED 
tcp        0      0 127.0.0.1:45009         127.0.0.1:7003          ESTABLISHED 
tcp        0      0 127.0.0.1:45008         127.0.0.1:7002          ESTABLISHED 
tcp        0      0 127.0.0.1:45011         127.0.0.1:7001          ESTABLISHED 
tcp        0      0 127.0.0.1:7014          127.0.0.1:45024         ESTABLISHED 
tcp        0      0 127.0.0.1:32852         127.0.0.1:6015          ESTABLISHED 
tcp        0    512 134.138.187.113:22      134.138.186.45:32895    ESTABLISHED 
tcp        0      0 134.138.187.113:22      134.138.186.33:35940    ESTABLISHED 
tcp        0      0 134.138.187.113:22      134.138.186.45:34915    ESTABLISHED 
tcp        0      0 172.16.16.129:873       172.16.17.1:47401       TIME_WAIT   
tcp        0      0 172.16.16.129:873       172.16.17.1:47400       TIME_WAIT   
tcp        0      0 172.16.16.129:873       172.16.17.1:47399       TIME_WAIT   
tcp        0      0 134.138.187.113:22      134.138.186.45:32819    ESTABLISHED 
tcp        0      0 134.138.187.113:22      134.138.186.3:37119     ESTABLISHED 
tcp        0      0 134.138.187.113:22      134.138.186.45:32897    ESTABLISHED 
udp        0      0 0.0.0.0:32768           0.0.0.0:*                           
udp        0      0 0.0.0.0:2049            0.0.0.0:*                           
udp        0      0 0.0.0.0:514             0.0.0.0:*                           
udp        0      0 0.0.0.0:6666            0.0.0.0:*                           
udp        0      0 0.0.0.0:43149           0.0.0.0:*                           
udp        0      0 0.0.0.0:43150           0.0.0.0:*                           
udp        0      0 0.0.0.0:43151           0.0.0.0:*                           
udp        0      0 0.0.0.0:43152           0.0.0.0:*                           
udp        0      0 0.0.0.0:43153           0.0.0.0:*                           
udp        0      0 0.0.0.0:43154           0.0.0.0:*                           
udp        0      0 0.0.0.0:43155           0.0.0.0:*                           
udp        0      0 0.0.0.0:43156           0.0.0.0:*                           
udp        0      0 0.0.0.0:43157           0.0.0.0:*                           
udp        0      0 0.0.0.0:43158           0.0.0.0:*                           
udp        0      0 0.0.0.0:43159           0.0.0.0:*                           
udp        0      0 0.0.0.0:43160           0.0.0.0:*                           
udp        0      0 0.0.0.0:43161           0.0.0.0:*                           
udp        0      0 0.0.0.0:43162           0.0.0.0:*                           
udp        0      0 0.0.0.0:43163           0.0.0.0:*                           
udp        0      0 0.0.0.0:43164           0.0.0.0:*                           
udp        0      0 0.0.0.0:43165           0.0.0.0:*                           
udp        0      0 0.0.0.0:43166           0.0.0.0:*                           
udp        0      0 0.0.0.0:43167           0.0.0.0:*                           
udp        0      0 0.0.0.0:43168           0.0.0.0:*                           
udp        0      0 0.0.0.0:43169           0.0.0.0:*                           
udp        0      0 0.0.0.0:43170           0.0.0.0:*                           
udp        0      0 0.0.0.0:43171           0.0.0.0:*                           
udp        0      0 0.0.0.0:43172           0.0.0.0:*                           
udp        0      0 0.0.0.0:43173           0.0.0.0:*                           
udp        0      0 0.0.0.0:43174           0.0.0.0:*                           
udp        0      0 0.0.0.0:43175           0.0.0.0:*                           
udp        0      0 0.0.0.0:43176           0.0.0.0:*                           
udp        0      0 0.0.0.0:43177           0.0.0.0:*                           
udp        0      0 0.0.0.0:43178           0.0.0.0:*                           
udp        0      0 0.0.0.0:4011            0.0.0.0:*                           
udp        0      0 0.0.0.0:5556            0.0.0.0:*                           
udp        0      0 0.0.0.0:67              0.0.0.0:*                           
udp        0      0 0.0.0.0:69              0.0.0.0:*                           
udp        0      0 0.0.0.0:843             0.0.0.0:*                           
udp        0      0 0.0.0.0:728             0.0.0.0:*                           
udp        0      0 0.0.0.0:7000            0.0.0.0:*                           
udp        0      0 0.0.0.0:111             0.0.0.0:*                           
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ACC ]     STREAM     LISTENING     774397 /tmp/ssh-XXwxLoep/agent.10414
unix  2      [ ACC ]     STREAM     LISTENING     1449986 /tmp/ssh-XXlipTLv/agent.24208
unix  2      [ ACC ]     STREAM     LISTENING     1451202 /tmp/ssh-XX1taPRQ/agent.25090
unix  2      [ ACC ]     STREAM     LISTENING     1451281 /tmp/ssh-XXtKX9jU/agent.25154
unix  2      [ ACC ]     STREAM     LISTENING     3366149 /tmp/ssh-XXkFUPqK/agent.11671
unix  2      [ ACC ]     STREAM     LISTENING     4104981 /tmp/ssh-XXz330QB/agent.12210
unix  11     [ ]         DGRAM                    1009   /dev/log
unix  2      [ ]         DGRAM                    5724723 
unix  2      [ ]         DGRAM                    5649909 
unix  2      [ ]         DGRAM                    5644881 
unix  2      [ ]         DGRAM                    5625224 
unix  2      [ ]         DGRAM                    5348443 
unix  2      [ ]         DGRAM                    2455   
unix  2      [ ]         DGRAM                    1146   
unix  2      [ ]         DGRAM                    1050   
unix  2      [ ]         DGRAM                    1019   
unix  2      [ ]         STREAM     CONNECTED     484    
 

Run the scripts stop_services and start_services.

Rerun the "configureTelORB -c" script.

Use Ethereal and check if you get any error messages, e.g. the ICMP message
"unreachable destination - port unavailable".

-  -  -  -  -  -

There is a workaround for this problem where a crontab job checks if TFTP is
hanging every minute and if it is hanging the crontab job restarts the xinetd
process on the IO processor.
Verify that the crontab job is running:
  su
  tail -f /var/log/messages                                (Ctrl-c to stop tail)

  Look for the following string which should appear every minute:
  "Nov  1 10:09:00 to28io1 logger: xinetd/in.tftp is ok."


EpTftpd process keeps cloning
If the EpTftpd process keeps cloning like this:

telorb   14989 10653  0 13:13 ?        00:00:00 [EpTftpd.LM_MD41 <defunct>]
telorb   14990 10653  0 13:13 ?        00:00:00 [EpTftpd.LM_MD41 <defunct>]
telorb   14991 10653  0 13:13 ?        00:00:00 [EpTftpd.LM_MD41 <defunct>]
telorb   14992 10653  0 13:13 ?        00:00:00 [EpTftpd.LM_MD41 <defunct>]
telorb   14993 10653  0 13:13 ?        00:00:00 [EpTftpd.LM_MD41 <defunct>]

Check that the ownership of the file tftpdPortServer is:
  ls -l /tmp/tftpdPortServer
    "0 srwxrwxrwx    1 telorb   uab         0 Oct 12 13:19 tftpdPortServer"

It should not be:
srwxrwxrwx    1 root     root            0 Oct 11 13:50 tftpdPortServer


Removable start files on IO processors
If the following start files exist on an IO processor with Linux OS below
directory /etc/rc3.d/, they can be removed with the rm command as follows:

/bin/rm S08ip* S15nfs S20random S25netfs S26apmd S28autofs S40atd S56rawdevices S60lpd S80* S85gpm S90xfs S95anacron


Harmless printouts in the TelORB processor consoles
- Couldn't publish Direct Access Filesystem (DAFS).

- The "Bad phy addr in EEPROM, scanning" printout from the booting part of a
  TelORB processor can be ignored.
  It just shows that a work-around solution for a hardware problem works.
  The real hardware problem will be fixed (by Solectron?) later.
  The processor and its eth-interfaces should be fully functional, in spite of
  this printout. I have issued TR UABtr06019 for this.
  For a TelORB processor with TelORB OS, printouts for both external interfaces
  may be received.
  For a TelORB processor with Linux OS, one printout for one of the external
  interfaces may be received.


Reference values from ulinpc34
  cd /etc/sysconfig/
  cat network
    NETWORKING=yes
    HOSTNAME=ulinpc34
    GATEWAY=134.138.184.1
  cd /etc/sysconfig/network-scripts/
  ls ifcfg-eth*
    ifcfg-eth0  ifcfg-eth1  ifcfg-eth2
  cat ifcfg-eth0 (default)
    DEVICE=eth0
    BOOTPROTO=static
    BROADCAST=134.138.191.255
    IPADDR=134.138.184.193
    NETMASK=255.255.248.0
    NETWORK=134.138.184.0
    ONBOOT=yes

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Modified and new IDPs for the TSP 4.0 Clusterware and OS project
 (Updated: 2001-10-05)

Move this part elsewhere later:

- Dicos_IDP - A replacement IDP/MD14 which contains
  some of the fixes needed for TSP4.0.

- Ethernet_IDP - A replacement IDP/MD16 which contains some 
  corrections in order to be able to talk to Linux processors.

- TelorbLinux_IDP - The basic IDP for running Linux which should be 
  included in your epct file.

- TelorbLinuxTotal_IDP - Further IDP for running Linux which must
  also be included in your epct file.

- TelorbLinuxJava_IDP - An IDP containing Java for Linux, which should
  be included in epct files if you want to run Java applications on Linux.


- LinuxScripts_IDP - A "fake" IDP containing just an RPM which should
  be installed on the Linux SPs, once the Linux installation is complete.

- RH7.1_Disk1_IDP - A "fake" IDP containing disk 1 of Redhat Linux 7.1
  This should be used as part of setting up a JumpStart server for installing
  IO machines

- RH7.1_Disk2_IDP  - A "fake" IDP containing disk 2 of Redhat Linux 7.1
  This should be used as part of setting up a JumpStart server for installing
  IO machines. Obtain this from
  ftp://ftpmirror.ericsson.se/pub/MIRRORS/OS/Linux/redhat/redhat/linux/7.1/en/iso/i386/

- RH7.1_Extras_IDP - A "fake" IDP containing some extra packages for Linux
  This should be used as part of setting up a JumpStart server for installing
  IO machines. Obtain this from
  ftp://ftpmirror.ericsson.se/pub/MIRRORS/OS/Linux/redhat/redhat/linux/7.1/en/iso/i386/

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Extras
 (Updated: 2001-12-10)

Reload of a "Linux processor" during a backup should NOT affect the backup,
whereas a reload of a "TelORB processor" during a backup should result in a
failed backup.

General
 (Updated: 2001-11-14)

This section is valid from TelORB R14/TSP 4.0 Clusterware & OS.

It is possible to verify the file system mount points from a TelORB processor
point of view, by following the instructions below.

You can also use the TelORB Manager to get a general view of the file system
mountings. Select the "DNS/NFS" card and click the "Refresh" button below the
"File System Configuration" heading.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check file system mountings from a TelORB processor with TelORB OS
 (Updated: 2001-11-14)

telnet 134.138.59.131 8000                (Adjust IP address to valid TelORB TP)
cd filesystem
ls
	Example of printout (shows which commands that can be used):
	  lsd*
	  mkdir*
	  cdd*
	  pwdd*
	  catd*
	  mv*
	  cp*
	  ln*
	  rm*
	  rmdir*
	  mknod*
	  mount*
	  umount*

lsd
	Example of printout:
	  .
	  ..
	  dev
	  loadingGroup01_1
	  loadingGroup01_2
	  upgradePackages

lsd loadingGroup01_1
	Example of printout:
	  .
	  ..
	  codeArchive
	  java
	  initialData
	  Processor1
	  Processor2
	  Processor3
	  Processor4
	  Processor5
	  Processor6
	  Processor7
	  Processor8
	  Processor9
	  Processor10
	  backups
	  networkAddresses
	  DicosEnvironment
	  Outage
	  .activeVersion

	Example of printout when the processor cannot reach loadingGroup01_1:
          lsd: failed errno = 9

lsd upgradePackages
	Example of printout:
	  .
	  ..
	  upgrade_package01
	  upgrade_package02

Check active backup version:
catd loadingGroup01_1/.activeVersion
          Backup1

quit

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Check file system mountings from a TelORB processor with Linux OS
 (Updated: 2001-11-14)

telnet 134.138.59.134                      (Adjust IP address to valid Linux TP)

login: telorb
Password:

ls /opt/telorb/axe/
	loadingGroup01_1  loadingGroup01_2

ls /opt/telorb/axe/loadingGroup01_1
	DicosEnvironment  Processor12  Processor17  Processor5	backups
	Outage		  Processor13  Processor18  Processor6	codeArchive
	Processor1	  Processor14  Processor2   Processor7	initialData
	Processor10	  Processor15  Processor3   Processor8	java
	Processor11	  Processor16  Processor4   Processor9	networkAddresses

quit

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Change file system mountings from the TelORB Manager
 (Updated: 2003-07-02)

If, for some reason, a mount point (e.g. to /opt/telorb/axe/loadingGroup1_1) is
marked red in the "DNS/NFS" card in the TelORB Manager, try unmounting and
mounting again as follows:

- Add the following lines, taken from the epct file (e.g.
  r14_linux_mini_zone2.epct) in the TelORB Manager's "DNS/NFS" card (below File
  System Commands).
  Only enter what is specified within the "  " characters in the epct file:
    umount /dev/rpc1                       (For /opt/telorb/axe/loadingGroup1_1)
    (mkdir /loadingGroup01_1)              (May not be necessary)
    (mknod -b /dev/rpc1 2 1)               (May not be necessary)
    mount -t nfs -o uid=44622 -o gid=33 -o ipaddr=172.16.100.101 -o ipaddr=172.17.100.101 /dev/rpc1 /loadingGroup01_1/ /opt/telorb/axe/loadingGroup01_1"

General
 (Updated: 2003-05-26, TelORB R14/TSP 4.0)

From TelORB Manager, DNS/NFS card:
  File System Command input:
    mkdir testFSmount
    mknod -b /dev/rpc5 2 5
    mount -t nfs -o uid=44622 -o gid=33 -o ipaddr=172.16.0.1 -o ipaddr=172.16.8.1 /dev/rpc5 /testFSmount/ /data

File System Configuration: Click "Refresh".
Verify that the mounting is visible.

Restore from TelORB Manager, DNS/NFS card:
  File System Command input:
    umount /testFSmount/


On IO processor:
  su
  Password:
  cd /
  mkdir testFSmount
  mount 172.16.0.1:/data /testFSmount  (Use File Server IP address)
  exit
  cd /testFSmount

  cp /opt/telorb/etc/telorb.conf .

On File Server:
  cd /data
  ls -l
  Verify that telorb.conf is shown.

Restore IO processor:
  rm -rf /testFSmount

Log in to IO processor via serial cable
Log in to the `target' IO processor by using e.g. the command tip, see
Connect to remote host using "tip" and then return to this section.


Old description when seyon was used
Connect a cable from the COM1 (SERIAL A+B) port of IO processor 2 to the COM1
  (cua0) or COM 2 (cua1) port of e.g. to2io1. (to2io1 is used to get access to
   the communication program seyon, i.e. seyon is located on to2io1)
For seyon, use an xterm window.
telnet to2io1                     (Log in to IO processor 1)
login: telorb                     (Type user name)
Password:                         (Type password)

telnet to2io1                      (Log in to IO processor 1)
login: telorb                      (Type user name)
Password:                          (Type password)
(setenv DISPLAY 134.138.186.xx:0.0  (Set IP address of the WS to display on.
                                     Adjust the IP address to the WS that you
                                     are working on))
su root
ls                              (Check that seyon files exist)
./seyon -modems /dev/cua1       (Or cua0 depending on if port COM1 or COM2
                                 is used) (Starts windows "Seyon Command Center"
                                 and "Seyon Terminal Emulator".)
Press reset button on IO processor 2.
Press abort button on IO processor 2 after a while to stop cyclic reboots.

To break a printout, give Ctrl-d and Ctrl-c rapidly after one another.

Continue by following the official TelORB OPIs.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Solaris versions
Solaris 7 was introduced in AD12. Before AD12, Solaris 2.6 was used.

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints 1
To get from "ok" prompt to "#" prompt (ioY console login) give command
"boot disk".

== == == == == == == == == == == == == == == == == == == == == == == == == ==

Hints 2
To install Solaris on e.g. a jumpstart server, do as follows:
  - If the jumpstart server is up and running, copy files that you want to keep,
    if any, and then halt the jumpstart server (as root) and power it off.
  - Power on the jumpstart server and let it boot.
  - Insert the Solaris CD in the CD drive.
  - Enter the following commands:
      su           (Enter root password)
      halt         (Will return ok prompt)
      boot cdrom   (Boot from CD ROM)
  - Follow the instruction wizard and enter appropriate values.

cd /home/dicoshack/Hack/qabpea/toinstall
qabpea/toinstall>ls
fe.tar        installs.txt  ro.tar        tor.tar       
ins.log       pub.tar       to.tar        
qabpea/toinstall>more installs.txt 
" /" find-device " SUNW,Ultra-5_10" encode-string " compatible" property device-
  end
nvedit
" /" find-device " SUNW,Ultra-5_10" encode-string " compatible" property device
  end

nvstore
setenv use-nvramrc? true

setenv boot-device cdrom
reset

cd /a/var/spool/pkg

pkgadd -d /cdrom/Solaris_2.5.1 -s /a/var/spool/pkg SMEvplr.u SMEvplu.u
  SUNWvplr.u SUNWvplu.u SUNWkmp2r.u SUNWmui

pkgadd -d . -R /a SMEvplr.u SMEvplu.u SUNWvplr.u SUNWvplu.u SUNWkmp2r.u SUNWmui
y
y
halt                            (Not necessary to sync before halting)

setenv boot-device disk
setenv use-nvramrc? false 

reset 

General
 (Updated: 2001-09-05)

The exp0, exp1, hme0 and hme1 ports have fixed positions on all TelORB IO
processors (Carmencita hardware) and are as follows:

      IO processor board
          ---------
          |   |   |
          |   | # | exp1 (PMC 2)
          |   |   |
          |   |   |
          | # |   | hme0 (ETHERNET)
          |   |   |
          |   |   |
          |   | # | exp0 (PMC 1)
          |   |   |
          |   |   |
          |   | # | hme1 (ETHERNET)
          |   |   |
          ---------

To check where the ports are assigned to, log in to the IO processor and enter
the following command:
  ifconfig -a

    Printout example for TelORB system to14:
      lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
              inet 127.0.0.1 netmask ff000000 
      exp0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
              inet 134.138.57.25 netmask ffffff80 broadcast 134.138.57.127
      exp1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
              inet 134.138.58.25 netmask ffffff80 broadcast 134.138.58.127
      hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
              inet 134.138.187.54 netmask fffff800 broadcast 134.138.191.255

From the printout example one can determine where the ports are connected to,
i.e.:
  exp0: Ethernet switch A (Traffic network 1) (i.e. 134.138.57) (to14io1i2)

  exp1: Ethernet switch B (Traffic network 2) (i.e. 134.138.58) (to14io1i3)

  hme0: External network (users) (i.e. 134.138.187 = pink LAN at the EAB
        CW/OS lab) (to14io1)

  hme1: External network (extra interface (backup network)) (Not used in to14)

To modify e.g. exp0, do as follows:
  ifconfig exp0 inet 134.138.57.25 broadcast 134.138.83.255 (not verified yet)

-  -  -  -  -  -  -  -  -  -

To get more information about the IO processor ports exp0, exp1, hme0 and hme1
of an IO processor, log in to the IO processor and enter the following commands:
  cd /etc/
  more hostname*
    Printout example:
      ::::::::::::::
      hostname.exp0
      ::::::::::::::
      to14io1i2
      ::::::::::::::
      hostname.exp1
      ::::::::::::::
      to14io1i3
      ::::::::::::::
      hostname.hme0
      ::::::::::::::
      to14io1

  more hosts
    Printout example:
      #
      # Internet host table
      #
      127.0.0.1       localhost       
      134.138.187.54  to14io1 loghost
      134.138.57.25   to14io1i2
      134.138.58.25   to14io1i3

      134.138.187.55  to14io2
      134.138.57.26   to14io2i2
      134.138.58.26   to14io2i3
      134.138.57.25      to14io1.i2
      134.138.58.25      to14io1.fe1

General
 (Updated: 2002-01-15)

These instructions are valid from TelORB R14 and onwards.

If you want to run a TelORB system with only one IO processor, e.g. IO1, do as
follows:
- Physically disconnect IO2 from the magazine backplane.
- Comment out the following lines for IO2 from the epct file (e.g.
  telorbDataLocal.epct) by inserting a hash sign (#) in front of the lines:
    FileSystemCommand_50 = "mkdir /loadingGroup01_2"
    FileSystemCommand_60 = "mknod -b /dev/rpc2 2 2"
    FileSystemCommand_70 = "mount -t nfs -o proto=udp -o rsize=8192 -o wsize=8192 -o nmbofreadbuf=2 -o nmbofwritebuf=6 -o uid=44622 -o gid=33 -o ipaddr=134.138.59.226 -o ipaddr=134.138.60.226 -o hostname=to28io2 /dev/rpc2 /loadingGroup01_2/ /opt/telorb/axe/loadingGroup01_2"
- When building the system, in the epct command, exclude the string
  "-f loadingGroup01_2", e.g.
  epct -t i486 -vFc -f loadingGroup01_1 -d ../axe name.epct ../../epct/ad14/telorbDataGeneral.epct telorbDataLocal.epct telorb.epct ../processor.epct
  ("-t i486" is not necessary) 

General
 (Updated: 2002-04-12)

To configure 3 additional (fake) file system mount points on an IO processor
(for testing reasons), do as follows:
- Create e.g. directories mount1, mount2 and mount3 on e.g. IO2:
    cd /opt/telorb/axe/
    mkdir mount1
    mkdir mount2
    mkdir mount3

- Add the following lines to the epct file (telorbDataLocal.epct) or enter them
  manually from the TelORB Manager (File System Commands) (When using the
  TelORB Manager, only enter what is specified within the "  " characters):
    FileSystemCommand_51 = "mkdir /mount1"
    FileSystemCommand_61 = "mknod -b /dev/rpc4 2 4"
    FileSystemCommand_71 = "mount -t nfs -o proto=udp -o rsize=8192 -o wsize=8192 -o nmbofreadbuf=2 -o nmbofwritebuf=6 -o uid=44622 -o gid=33 -o ipaddr=134.138.63.226 -o ipaddr=134.138.64.226 -o hostname=to21io2 /dev/rpc4 /mount1/ /opt/telorb/axe/mount1"

    FileSystemCommand_52 = "mkdir /mount2"
    FileSystemCommand_62 = "mknod -b /dev/rpc5 2 5"
    FileSystemCommand_72 = "mount -t nfs -o proto=udp -o rsize=8192 -o wsize=8192 -o nmbofreadbuf=2 -o nmbofwritebuf=6 -o uid=44622 -o gid=33 -o ipaddr=134.138.63.226 -o ipaddr=134.138.64.226 -o hostname=to21io2 /dev/rpc5 /mount2/ /opt/telorb/axe/mount2"

    FileSystemCommand_53 = "mkdir /mount3"
    FileSystemCommand_63 = "mknod -b /dev/rpc6 2 6"
    FileSystemCommand_73 = "mount -t nfs -o proto=udp -o rsize=8192 -o wsize=8192 -o nmbofreadbuf=2 -o nmbofwritebuf=6 -o uid=44622 -o gid=33 -o ipaddr=134.138.63.226 -o ipaddr=134.138.64.226 -o hostname=to21io2 /dev/rpc6 /mount3/ /opt/telorb/axe/mount3"

- If the file system commands were entered via epct, you must build and initial
  load the TelORB system.